wazevo: initial work on constant folding

[evacchi]

#1496

This implements an initial, simple constant folding pass for add/sub/mul for i32/i64/f32/f64.
It also implements a new case for passNopInstElimination where one of the args is const 0.

• is it ok to mutate instructions in-place that way?
• do we need to add checks for integer underflow/overflow? the behavior right now is essentially whatever Go does (i.e. let integers wrap, let floats go to ±inf)
• todo: add a few more test cases

[mathetake]

I think this really needs fuzzing yeah

[mathetake]

yeah I think I would suggest to see how much overhead costs will be added like by compiling zig stdlib binray and let's have a reasonable O(1) upper bound

[evacchi]

even without an upper bound the pass seems to account for less than 1% CPU time against the Wasm library.

in terms of hard numbers, on my machine it compiles the wasm binary in about 7.02 seconds with the extra pass and 6.94-6.99 without

To be fair, that might not be surprising: e.g., if the wasm binary went through wasm-opt it might be already minimized, and if it weren't, operations between constants may not naturally occur in a Wasm binary very often (after all, it's already a compilation target)

[evacchi]

...in fact, I am not even sure how often this pass will be useful, I don't know how often we'll find cases in the wild. Anyway it's a useful playground for me...

Besides, other, related techniques such as constant tracking and constant propagation might still be beneficial, and the framework should be similar.

[evacchi]

I figured out what (silly) mistake I was making with my experiment with algebraic simplification (just add X, const1; add Y, const2 => add X, (const1+const2)). This, together with const-fold adds a more significant overhead (~7.4); but that should also mean that it does make some difference. On a first quick look, the first largest functions in the zig stdlib were not significantly smaller.

constFold, no simplification

1809672
1358096
906528

constfold + simplification

1809668
1358092
906524

[evacchi]

Memo to self https://developers.redhat.com/articles/2023/12/07/how-single-iteration-instcombine-improves-llvm-compile-time#removing_the_fixpoint_iteration

[mathetake]

The diff in the size(?) seems negligible to me even with simplification…

[evacchi]

yeah agreed (yeah that's size in bytes)

[evacchi]

I pushed some new simple substitutions extending nop elimination. Algebraic simplification need more research to be effective. Now rebased and running some fuzzing locally.

[evacchi]

closing for now as no significant benefit so far