The immediate goal is simply to inspire LLVM hackers to improve the instruction combiner.
But yes, these results can be made persistent and used directly to optimize code. We are working on it.
Applying this tool to code emitted by GHC or rustc is trivial, it's all LLVM bitcode. One of my ideas is that these languages are a good use case for a superoptimizer since the LLVM passes aren't tuned for them, but we'll have to see how that plays out.
What's neat is that not all of these end up needing the InstCombine pass to get optimized, some of them can be handled using InstSimplify. InstSimplify isn't a pass, it's an analysis that get's called upon many times in the middle of other passes, strengthening them.
> Finally C-Reduce has missed some opportunities to fold constants, so for example we see ~1 instead of -2 in the 2nd example from the top.
Do you compile the code using clang -O<level> or optimize using opt? I would think that InstCombine would canonicalize that for you so Souper would have less work to do.
Sorry if I was unclear. The missing folds are at the C level. At the LLVM level we definitely run InstCombine before Souper (otherwise we would find lots of optimizations that are not actually missing).
But yes, these results can be made persistent and used directly to optimize code. We are working on it.
Applying this tool to code emitted by GHC or rustc is trivial, it's all LLVM bitcode. One of my ideas is that these languages are a good use case for a superoptimizer since the LLVM passes aren't tuned for them, but we'll have to see how that plays out.