[dart2wasm] Revisit binaryen flags we use when compiling apps

[mkustermann]

The list of binaryen flags we have been using hasn't been changed in a long time, despite us having added various optimizations on our side, including more devirtualization of calls (including closure calls), ...

We also have now a good set of large applications that compile under dart2wasm we can use as a measurement stick:

• Wonderous
• DevTools
• Flute
• ACX Gallery
• Hello world

We should re-visit the binaryen passes we run (order, number and type of pass) while not only looking at the size of the above, but also aiming for spending less compilation-time.

[osa1]

I think we just have to implement some kind of automated search and try different permutation of flags in an automated way. There's no other way that's not extremely time consuming for us, and with very little benefit for each hour wasted.

For example, a tool could be written (maybe with some help from the LLMs) that will take as inputs:

1. A script/command that will be appended with optimization flags
2. A script/command that will generate some kind of "score" based on the output file
3. And maybe another script/command that will compare scores generated in the previous command, and maybe generate a score of how much better a new score is.

As output it would try passing different combination of flags to (1), compare the score with the current best score (or some number of scores, depending on the search algorithm).

Yes the search space is massive -- even if we limit number of arguments to pass to e.g. 10, wasm-opt has a lot of passes and flags, but the search space is the same regardless of whether I do this automatically or manually, and whathever heuristics I use to do this manually I can probably hard-code into the tool as well.

I spent an hour today and found out that --gufa-optimizing runs in about the same time with --gufa, but saves a few bytes, and improves code on ACX. Now there are maybe 50 more flags that I can try, at different positions..

There's another way which we're already exploring: we look at the code and try to detect optimization opportunities. Then see which wasm-opt pass can do it, and try to improve wasm-opt passes if necessary. I'm already doing this with binaryen PRs 1 and 2, and I have a planned improvement to "loop invariant code motion" pass. But if we want to just experiment with the flags, I think manually doing it is a waste of time.

Edit: I also noticed that --generate-global-effects helps with binary sizes when I run it before the last -Os. (I don't know about other positions)

[osa1]

I've made some progress on this front.

I improved wasm-opt's flattening pass in WebAssembly/binaryen#7939 which allows us to use -O4 and --licm. (loop invariant code motion)

I tried DeltaBlue with the -O4 flag, also with and without adding --monomorphize. All flags here are kept the same except I replaced -Oss with -O4 (and with -O4 --monomorphize).

The reason why I also wanted to try --monomorphize is that wasm-opt doesn't inline functions like this even with -O4:

(func $BoxedInt.<< (;59;) (param $var0 i64) (param $var1 i64) (result i64)
  local.get $var1
  i64.const 64
  i64.lt_u
  if
    local.get $var0
    local.get $var1
    i64.shl
    return
  end
  local.get $var1
  i64.const 0
  i64.lt_s
  if
    i32.const 41
    ref.null none
    i32.const 0
    ref.null none
    i32.const 98
    local.get $var1
    struct.new $BoxedInt
    struct.new $ArgumentError_6
    call $Error._throwWithCurrentStackTrace
    unreachable
  end
  i64.const 0
)

When the second argument to this function is a constant, all correct uses of this function are reduced to just one instruction (i64.const 0 after dropping the args, or i64.lt_s). And most of the uses (probably even all) pass a constant second argument (the shift amount).

wasm-opt only inlines this with -O4 --monomorphize.

Binary size results:

• -Os: 29,272 bytes
• -O4: 28,720 bytes
• -O4 --monomorphize: 28,352 bytes

Runtimes:

• -Os: 780 us
• -O4: 893 us
• -O4 --monomorphize: 857 us

So somehow it gets smaller as we optimize more aggressively, but it also get slower.

I don't know why it gets slower yet, the code looks much better in general.

So far I'm unable to use --licm effectively. It always increases binary sizes quite significantly and makes it run slower too. It's possible that I'm not using it with the right pass combination, or at the right place in the list of passes.

I also tried this with ACX gallery (single file .wasm, not with multiple modules). -O4 made it slightly larger: 20,811,566 bytes to 21,177,561 bytes. (1.7%)

[osa1]

I think we should try to make use of --monomorphize somehow. We've identified so many cases in the past (also see the BoxedInt.<< above) where a directly called function shrinks to just one instruction, or eliminates boxing, when inlined, but even -O4 doesn't inline some of those.

--monomorphize exists to solve this problem: https://github.com/WebAssembly/binaryen/blob/7ba340a934d17c3d8fc23ef9cd9f99e4e3ac4367/src/passes/Monomorphize.cpp#L18-L28

I don't know if it mixes well with -Os, but I think we should somehow make it work.