[EH] Add --experimental-new-eh option to wasm-opt

[aheejin]

This adds --experimental-new-eh option to wasm-opt. The difference between this and --translate-to-new-eh is, --translate-to-new-eh just runs TranslateToNewEH pass, while --experimental-new-eh attaches TranslateToNewEH pass at the end of the whole optimization pipeline. So if no other passes or optimization options (-On) are specified, it is equivalent to --translate-to-new-eh. If other optimization passes are specified, it runs them and at the end run the translator to ensure the new EH instructions are emitted. The reason we are doing this this way is that the optimization pipeline as a whole does not support the new EH instruction yet, but we would like to provide an option to emit a reasonably OK code with the new EH instructions.

This also means when the optimization level > 3, it will also run the StackIR + local2stack optimization after the translation.

Not sure how to test the output of this option, given that there is not much point in testing the default optimization passes, and it is also not clear how to print the stack IR if the stack ir generation and optimization runs as a part of the pipeline and not the explicit command line options.

This is created in favor of #6267, which added the option to optimization-options.h. It had a problem of running the translator multiple times when -On was given multiple times in the command line, which I learned was rather a common usage. This adds the option directly to wasm-opt.cpp, which avoids the problem. With this, it is still possible to create and optimize Stack IR unnecessarily, but that feels a better alternative.

[kripken]

Code lgtm.

I think a test would be good to add just to be safe. Maybe we can check in the result of --experiment-new-eh -O on a binary, and a lit test could just check that the result has not changed? (just a binary diff with a boolean outcome)

[aheejin]

Code lgtm.

I think a test would be good to add just to be safe. Maybe we can check in the result of --experiment-new-eh -O on a binary, and a lit test could just check that the result has not changed? (just a binary diff with a boolean outcome)

Not sure if I understand. What binary? (Old EH instructions or new ones?) Why does it have to be unchanged? And why would it be a binary test rather than a text one?

I can add a test showing that --experimental-new-eh does the same thing (translation) w/ --translate-to-new-eh when given alone. It is hard to test the combination of the translation and stack IR optimization because there is no way I can print the stack IR result with this.

[kripken]

I mean taking a file old.wasm with old wasm EH, running wasm-opt --experimental-new-eh -O -o new.wasm, and checking in both old.wasm and new.wasm. The test would run that same command and see that it is the expected binary.

If we had wabt available then we could diff the text of the output, but without that, I think we can just compare the binaries as a boolean. That is, in this PR we can manually verify with wabt or another tool that the binary is properly optimized, including stackIR opts have run. Then the test will make sure we don't regress on that test.

[tlively]

Instead of checking in binaries for the tests, could we have the lit test assemble input.wat using both --experimental-new-eh and a manual pipeline using --translate-to-new-eh and check that the results are the same?

Other than that, LGTM.

[aheejin]

Instead of checking in binaries for the tests, could we have the lit test assemble input.wat using both --experimental-new-eh and a manual pipeline using --translate-to-new-eh and check that the results are the same?

Do you mean

wasm-opt --experimental-new-eh [INPUT] -o [OUTPUT]

and

wasm-opt --translate-to-new-eh [INPUT] -o [OUTPUT]

produce the same output binary (from the given input wat file), when each of these is given as a standalone flag?

[tlively]

Yes, exactly. And maybe you could add the -O1 and --generate-stack-ir --optimize-stack-ir flags to get them to run the same optimization pipeline as well.

[aheejin]

@tlively PTAL 😀

[tlively]

LGTM with that comment, unless we can't get rid of the intermediate file, in which case LGTM as-is.

[tlively]

Can we do without the intermediate file here? (@kripken, I don't quite remember how the optimization-level and -O flags interact these days)

[aheejin]

I think we can do without it... Not sure why I thought otherwise. Will fix.

[aheejin]

Removed the intermediate file. Will merge this. Thanks!