WebAssembly / WebAssembly/binaryen
Run (basic) StackIR optimizations in all binary writes?
Nobody has claimed this yet.
- Dominant language
- WebAssembly
- Stars
- 8.6k
- Forks
- 885
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 69
Description
Atm we enable StackIR optimizations in -O3 and -Os and above. This made sense because their benefit is usually fairly small, around 1-2%, and we didn't want to slow down builds just for that. However, maybe it is worth changing that, for two reasons:
- Our past worry about slowing down builds is perhaps not relevant today: Most and perhaps all toolchains using Binaryen are not running it in debug builds. Emscripten for example stopped running
wasm-optin debug builds and even in-O1(it only runs in-O2+), and other toolchains likewise have fast iteration/debug builds that just skipwasm-optentirely. Ifwasm-optis only run when it is meant to optimize, then there is little harm in running StackIR opts. - StackIR opts improve roundtripping in some cases, which is actually the immediate reason that made me think about this. Things like multivalue end up adding more locals and sets/gets in some cases, and StackIR opts can get rid of a bunch of those. Ideally we'd get to a point where roundtripping a file only shrinks it or keeps it the same size (which may require more than StackIR, but StackIR would be an important part of it). That is, better roundtripping is an additional goal here, beyond the 1-2% that StackIR normally helps.
- It would be simpler to just always run StackIR (at least the basic, non-costly parts) all the time, rather than the current system where we have passes to generate and optimize it, and there are various corner cases like what happens if you generate it but then modify BinaryenIR, etc. We can avoid that complexity by always running StackIR in binary writing.
StackIR does have some slower optimizations, which could be enabled only when the user requests a higher optimization level, which the binary writer would check.
(context: https://github.com/WebAssembly/binaryen/pull/6390 and another approach I am trying to fix that same problem as that PR may end up adding more roundtrip artifacts in rare cases, so I was wondering about ways to mitigate that.)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in the binary writer and trace how StackIR is currently generated and optimized for each optimization level. Compare the basic, non-costly passes with the slower ones and check roundtripping behavior around multivalue cases. Done means basic StackIR optimization runs during binary writing while higher-cost passes still follow the requested optimization level.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- wasm
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100