See test.wast and test.txt for an example of this in use. The superoptimizer suggests the optimization rule (x << 1) << 1 => x << 2.

I'm curious and would like to ask you a question, if you excuse my ignorance.
Why did you decide to have the superoptimizer running on the wast? And not on the LLVM representation?

Well, LLVM is just one thing that can produce wasm. Binaryen's optimizer should be able to optimize any wasm from any compiler, so having a superoptimizer here would benefit all those. Not many exist yet, of course, but hopefully they will.

I also think it's convenient to superoptimize in Binaryen - the technique used here requires the ability to execute code, which is trivial in Binaryen (using the built-in interpreter), but not practical in LLVM.

Ok, running the superoptimizer, it found a bunch of things missing in our optimizer, which I implemented in the 4 linked PRs (details in each one).

The total benefits of those PRs:

• Code size is reduced by mostly around 0.5%, however some codebases benefit more significantly, such as Lua by 1.0%. Unity shrinks by 0.7%.
• Most benchmarks don't benefit, but there are a few with 0.5%-1.0% speedups, and a few benefit more significantly, notably lua-scimark is 3% faster and bullet is 2% faster.

Those PRs seem to cover most of what the superoptimizer finds for now - we'll need to improve it to find more, lots of TODOs in the superoptimizer source, it's really very naive so far. Nice that even with such a simple superoptimizer we can find useful improvements.

As for this PR itself, for me personally it would be convenient to merge it, but possibly not worth it to increase build times for everyone, it could stay on this side branch. Thoughts?

Let's close this, the optimizations from this are helpful, but probably not much sense in getting the superoptimizer itself in-tree. It can stay in a side branch.

I'm doing more experiments here, and restoring/updating this branch.

Amazing! I expect it would be very helpful to run this on SIMD programs. In particular, if we could randomly generate vectorized LLVM programs, run them through the Wasm backend, then run them through the Binaryen superoptimizer to see what we missed in ISel, I think that would help use make significant improvements in LLVM.

Ah, interesting, I hadn't thought about SIMD... makes sense it could help. I think the code will need some changes for v128 but hopefully not many.

My motivation was mainly wasm GC, where more toolchains are not using LLVM. The old superoptimizer results were only on LLVM output, so there might be more or different opportunities now.

Side note, I reopened this branch, but I do not have the power to reopen this PR... and new commits I've pushed are not showing up.. 🤷 I guess I'll open a new PR with the updated code.