Add full LTO build of wasi-libc and libc++ #436

yamt · 2024-07-12T13:01:25Z

redo #424 after cmake migration

alexcrichton

As a high-level question, does Clang support embedding LLVM IR in object files? That's, for example, how the Rust compiler works without having two entirely different builds of the standard library. The single precompiled binary for the standard library supports both LTO and non-LTO builds.

alexcrichton · 2024-07-15T15:41:07Z

cmake/wasi-sdk-sysroot.cmake

+
+function(define_libcxx target)
+  define_libcxx_sub(${target} "" "" "")
+  define_libcxx_sub(${target} "-lto" "-flto=full" "/llvm-lto/${llvm_version}")


Is this /llvm-lto/$version convention something codified by Clang itself? Or something we're making up here in wasi-sdk?

This is something that was created/added specifically for the wasm clang driver: https://github.com/llvm/llvm-project/blob/0309709a6786653da7164334c83b09c9f37b943a/clang/lib/Driver/ToolChains/WebAssembly.cpp#L206-L212

See https://reviews.llvm.org/D70677

Ah ok! Could that be documented here that the convention is derived from LLVM itself?

i added a comment

alexcrichton · 2024-07-15T15:42:49Z

cmake/wasi-sdk-sysroot.cmake

+    COMMAND
+      ${MAKE} -j8 -C ${build_dir}
+        CC=${CMAKE_C_COMPILER}
+        AR=${CMAKE_AR}
+        NM=${CMAKE_NM}
+        SYSROOT=${wasi_sysroot}
+        EXTRA_CFLAGS=${extra_cflags}
+        TARGET_TRIPLE=${target}
+        ${extra_make_flags_lto}


Could this be split into a separate build rule with a separate build directory? I think it'd be reasonable to add an option to disable/enable the LTO builds and having it bundled in here will make it difficult to separate out. For debugging it would also be useful to have a single build target for just LTO or just without LTO.

do you mean to make 4 more copies of wasi-libc source tree?

Until wasi-libc supports out-of-tree builds yes I think that will be required.

sbc100 · 2024-07-15T15:49:00Z

As a high-level question, does Clang support embedding LLVM IR in object files? That's, for example, how the Rust compiler works without having two entirely different builds of the standard library. The single precompiled binary for the standard library supports both LTO and non-LTO builds.

I've never heard of that before. I've only ever seen separate object files/libraries used. I'm very curious to learn about this feature!

yamt · 2024-07-15T15:57:25Z

As a high-level question, does Clang support embedding LLVM IR in object files? That's, for example, how the Rust compiler works without having two entirely different builds of the standard library. The single precompiled binary for the standard library supports both LTO and non-LTO builds.

llvm has a concept called "fat lto object".
but it doesn't support wasm right now.

alexcrichton · 2024-07-15T16:01:55Z

The Rust compiler at least has a flag to embed bitcode in the original object file itself. It generates LLVM IR, uses that to generate an object file, then encodes the LLVM IR and puts that in the object file as well. Then when LTO is performed the compiler will recognize this type of file, extract the LLVM IR, and then process it as if it were LTO. The original object never gets passed to the linker in LTO builds.

LTO works relatively differently in Rust than it does in C/C++ though. Contrary to the name it's all done within rustc itself, rustc by default doesn't rely on the linker to perform LTO. Whether or not that would work here I'm not sure, but given that there's only a single linker in the wasm ecosystem and compiler it would be pretty nice to avoid two entirely separate builds of wasi-libc/etc to be configured just right to get LTO.

sbc100 · 2024-07-15T16:08:58Z

The Rust compiler at least has a flag to embed bitcode in the original object file itself. It generates LLVM IR, uses that to generate an object file, then encodes the LLVM IR and puts that in the object file as well. Then when LTO is performed the compiler will recognize this type of file, extract the LLVM IR, and then process it as if it were LTO. The original object never gets passed to the linker in LTO builds.

LTO works relatively differently in Rust than it does in C/C++ though. Contrary to the name it's all done within rustc itself, rustc by default doesn't rely on the linker to perform LTO. Whether or not that would work here I'm not sure, but given that there's only a single linker in the wasm ecosystem and compiler it would be pretty nice to avoid two entirely separate builds of wasi-libc/etc to be configured just right to get LTO.

I was unaware of the "fat lto object" thing until today.

Today in emscripten we generate separate versions of all the core libraries, just like is being proposed here.

I think this approach used in this PR is pretty reasonable, at least for now, given that:

The "fat LTO" format does not yet exist for wasm
The "LTO directory" thing is already part of the clang driver
emscripten also uses the "separate libs in a subdirectory" thing.

Perhaps one day, if we ever get around to adding "fat LTO" support we can revisit all of this.

alexcrichton · 2024-07-15T16:11:46Z

To be clear I wasn't saying this should all be held up to do something toally different, I was curious if something was possible. Sounds like it isn't. I think this is fine to land modulo a few small comments from myself above.

alexcrichton · 2024-07-15T18:12:30Z

cmake/wasi-sdk-sysroot.cmake

-function(define_libcxx target)
+execute_process(
+  COMMAND ${CMAKE_C_COMPILER} -dumpversion
+  OUTPUT_VARIABLE llvm_version


Can this also be called something like host_llvm_version or clang_llvm_version to better distinguish from clang_version? (either that or can that variable be renamed?)

my impression is clang_version should be retired. we can use -print-resource-dir instead.

Can you retire it in this PR then? Otherwise this is creating a confusing state where both are available and they refer to slightly different things.

i don't want to interfere with #445.

Now that #445 is merged could this be retired?

alexcrichton · 2024-07-17T17:05:23Z

Also one thing I just remembered as well, could a test be added for this? Or also I'm not sure how the existing tests interact with this because they're already passing -flto and passing, so I'm not sure how this relates to that.

yamt · 2024-07-17T22:44:25Z

Also one thing I just remembered as well, could a test be added for this? Or also I'm not sure how the existing tests interact with this because they're already passing -flto and passing, so I'm not sure how this relates to that.

the existing tests using -flto somehow cover this. i have already fixed a bug to pass them.

A downside: this makes four more copies of wasi-libc source tree.

yamt · 2024-07-24T05:18:24Z

the last push is a conflict resolution.

This was referenced Jul 12, 2024

Add full LTO build of wasi-libc and libc++ #424

Closed

Add LTO build option WebAssembly/wasi-libc#505

Merged

yamt force-pushed the lto3 branch from 2b97025 to c6dd073 Compare July 13, 2024 03:22

yamt marked this pull request as ready for review July 13, 2024 03:22

alexcrichton reviewed Jul 15, 2024

View reviewed changes

yamt added 6 commits July 24, 2024 14:16

Add LTO build of wasi-libc

bcfaad0

Add LTO build of libc++

afe909d

Update wasi-libc (to include the LTO support)

252deae

Add a comment about /llvm-lto/${llvm_version} convention

3432925

Use separate targets for wasi-libc with and without lto

6ab86ef

A downside: this makes four more copies of wasi-libc source tree.

Make LTO build optional

e7ceecb

yamt force-pushed the lto3 branch from 5f85d24 to e7ceecb Compare July 24, 2024 05:18

alexcrichton approved these changes Jul 24, 2024

View reviewed changes

alexcrichton merged commit 91ce489 into WebAssembly:main Jul 24, 2024
7 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add full LTO build of wasi-libc and libc++ #436

Add full LTO build of wasi-libc and libc++ #436

yamt commented Jul 12, 2024

alexcrichton left a comment

alexcrichton Jul 15, 2024

sbc100 Jul 15, 2024

alexcrichton Jul 15, 2024

yamt Jul 16, 2024

alexcrichton Jul 15, 2024

yamt Jul 15, 2024

alexcrichton Jul 15, 2024

yamt Jul 16, 2024

sbc100 commented Jul 15, 2024

yamt commented Jul 15, 2024

alexcrichton commented Jul 15, 2024

sbc100 commented Jul 15, 2024

alexcrichton commented Jul 15, 2024

alexcrichton Jul 15, 2024

yamt Jul 15, 2024

alexcrichton Jul 16, 2024

yamt Jul 16, 2024

alexcrichton Jul 17, 2024

yamt Jul 18, 2024

alexcrichton commented Jul 17, 2024

yamt commented Jul 17, 2024

yamt commented Jul 24, 2024

Add full LTO build of wasi-libc and libc++ #436

Add full LTO build of wasi-libc and libc++ #436

Conversation

yamt commented Jul 12, 2024

alexcrichton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbc100 commented Jul 15, 2024

yamt commented Jul 15, 2024

alexcrichton commented Jul 15, 2024

sbc100 commented Jul 15, 2024

alexcrichton commented Jul 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Jul 17, 2024

yamt commented Jul 17, 2024

yamt commented Jul 24, 2024