Wasm backend LTO docs and testing #8942
Conversation
| - The ``-flto`` flag tells the compiler to emit bitcode in object files, but does *not* affect system libraries. | ||
| - The ``-s WASM_OBJECT_FILES=0`` also flag tells the compiler to emit bitcode to object files, and also to use bitcode system libraries. | ||
|
|
||
| Thus, to allow maximal LTO opportunities with the LLVM wasm backend, build all source files with ``-s WASM_OBJECT_FILES=0`` and link with ``-s WASM_OBJECT_FILES=0 --llvm-lto 1``. |
There was a problem hiding this comment.
This is OK as a documentation of the existing status quo, but it's still pretty awkward and there are a lot of combinations of flags/behavior, not all of which are not useful. So it would be nice to simplify or line up with native a bit better. For example WASM_OBJECT_FILES is a legacy and it controls a lot of code that we can rip out once fastcomp is gone (we should be able to do what native platforms do and use lld to drive the LTO pipeline rather than driver code). Also if the only delta from -flto to NATIVE_OBJECT_FILES is that it also affects system libraries, then the name should reflect that, and it should only be required/allowed at link time. And --llvm-lto is a meaningless name when everything is done with LLVM.
There was a problem hiding this comment.
Agreed about simplifying this stuff later, yes.
Documents the -flto and WASM_OBJECT_FILES=0 options, which are not identical as the latter also affects system libraries. Also document that --llvm-lto 1 is needed to actually run lto opts (otherwise we pass --lto-O0 to wasm-ld). Add a test for -flto and WASM_OBJECT_FILES=0 emitting bitcode files as expected.
Documents the
-fltoandWASM_OBJECT_FILES=0options, which are not identical as the latter also affects system libraries. Also document that--llvm-lto 1is needed to actually run lto opts (otherwise we pass--lto-O0towasm-ld).Add a test for
-fltoandWASM_OBJECT_FILES=0emitting bitcode files as expected.