> Cheerp directly uses the LLVM bytecode format as the intermediate representation, for both object files and libraries.
The paragraph with this might be a little confusing. It suggests that this is a benefit of Cheerp, but upstream LLVM (and Emscripten, which uses upstream LLVM) can do the exact same thing if you build with -flto to enable LTO.
The benefit of upstream LLVM is that it can do both LTO and non-LTO builds. Non-LTO builds link much, much faster in a large project, since the linker is only concatenating wasm object files, just like a normal linker. That can matter a lot for CI times and local debugging etc.
Thanks for the input. This paragraph is indeed a selling point of Cheerp. "if you build with -flto to enable LTO" is only true if you run on Linux since LLVM LTO support on Windows and Mac is limited.
You can use upstream LLVM (and Emscripten, which uses it) with -flto normally on all platforms. It is basically cross-compiling, so it does not matter at all on what platform you are building, and Windows/Mac/Linux all work the same.
Just to confirm that, here is an Emscripten CI run on MacOS, where you can see among other tests ones that build with lto (search for "lto" in the "run tests" tab):
Limited in what way? LLVM LTO works seamlessly if you use LLD on both macOS and Windows; that's what Chrome does, for example. LLVM LTO also works pretty seamlessly with ld64 on macOS; the linker needs libLTO, but the driver takes care of that for you.
The paragraph with this might be a little confusing. It suggests that this is a benefit of Cheerp, but upstream LLVM (and Emscripten, which uses upstream LLVM) can do the exact same thing if you build with -flto to enable LTO.
The benefit of upstream LLVM is that it can do both LTO and non-LTO builds. Non-LTO builds link much, much faster in a large project, since the linker is only concatenating wasm object files, just like a normal linker. That can matter a lot for CI times and local debugging etc.