Understanding what's enabled under MVP

[jlb6740]

I've compiled wasm filters with maybe slightly different versions of wasm-opt but run in different versions of v8/envoy (many months apart). When using something like the --mvp-features flag to disable all non-mvp features I have seen notably different performance for certain codes. It was my understanding that mvp meant wasm-opt tries to use all features that can compile to I think what can be considered an mvp IR? Meaning even if a feature wasn't in the original wasm MVP it may still be used by Wasm-opt if it can compile to some satisfactory IR. Is this understanding correct? How do I best tell which optimizations are being used when compiling with the wasm-opt flag enabled? I've seen comments where someone had output that looked like it was maybe debug output of what PassRunner was doing, but I don't see any instructions on how to printout PassRunner info via the CLI or otherwise .. particularly when bazel is part of the mix.

[kripken]

Wasm MVP means basically what shipped in the first stable version of wasm back in 2015. So it doesn't include any features like sign-extension or nontrapping-float-to-int.

A simple way to see which optimizations run is to build with BINARYEN_PASS_DEBUG=1 in the env. That will log out each pass.

[jlb6740]

@kripken Thanks. So running means attempted right? Is there a way to differentiate between passes that are applied versus passes that are simply attempted?

[kripken]

Passes that the pass runner decides not to run (because the opt level is too low, or because they only work on features not enabled, etc.) are skipped and not mentioned. The passes you see printed out actually executed.

[jlb6740]

Thanks @kripken .. I was trying to distinguish between attempting the pass versus the pass actually transforming the code. For example, running a pass of loop invariant hoisting may call the pass function, but then if the pass realized there are no invariants to hoist would that show up in the list of passes as having executed? Frankly, I think I could just run a simple example and find out. In general I was looking for a way to suggest which optimizations are actually transforming the code and potentially having impact on code performance without doing some sort of binary search on run experiments.

[kripken]

Yes, a pass is listed if it tried to do work, even if it failed to do so.

If you want to track which passes do actual work, one option might be to add --metrics in between them. wasm-opt --metrics --precompute --metrics will print a diff in the second invocation of the metrics pass, which is compared to the previous one which in this case was before the precompute pass. You'll see +X and -X for changes, or nothing if nothing changed.