Conversation
|
This is pretty cool! |
|
For the threads-related code, you might need to use the |
| -DLLVM_INCLUDE_TESTS=OFF \ | ||
| -DLLVM_INCLUDE_UTILS=OFF \ | ||
| -DLLVM_INCLUDE_BENCHMARKS=OFF \ | ||
| -DLLVM_INCLUDE_EXAMPLES=OFF \ |
There was a problem hiding this comment.
I think we can/should probably land this hunk separately and without delay since I think it would speed up our builds.
There was a problem hiding this comment.
I wasn't sure if these things were needed. I'll have a look how much more work it is to support e.g. tests, that would help with validating the changes.
There was a problem hiding this comment.
They are not needed as far as I know, we don't use any of those binaries.
Doh! I saw you did that already right in the PR description, sorry. |
This is a recommendation from WebAssembly#304 to build less of LLVM in CI. Perhaps it can speed up build times.
This is a recommendation from WebAssembly#304 to build less of LLVM in CI. Perhaps it can speed up build times.
This is a recommendation from #304 to build less of LLVM in CI. Perhaps it can speed up build times.
|
I'm having trouble re-producing, but a thought occurred to me - could |
|
This is cool stuff! For wasi-sdk here, we'll need the LLVM changes to be submitted upstream. At a quick glance, the changes look reasonable, though I do suggest changing |
|
@sunny-g targeting WASIX instead of just WASI might reduce the changes needed to LLVM, but the result would only work in WASM runtimes with WASIX support -- AFAICS that is only wasmer at the moment |
Most of the change look like they relate to threading... hopefully those will not be needed once we have some kind of "null" pthread implementation in wasi-libc.. the remaining changes should be upstream-able I believe. |
|
I tried to update this to LLVM 18/HEAD 🚀 |
|
I wrote an LLVM RFC which proposes a fairly small patchset (two of them, specifically) that makes LLVM build on current WASI. With this patchset I'm able to build Clang and LLD, and compile and link functional Wasm files. |
|
@whitequark Great work properly "upstreaming" this! 👏 |
|
Thanks. Feel free to chime in on the RFC or the LLVM PR. |
|
From the RFC thread:
So, I think there is no need to maintain this as a patchset in the long term, and we should be able to have it all upstream. |
LLVM already has the |
7 participants
A few years ago, @binji ported LLVM/Clang 8 to WebAssembly/WASI: https://github.com/binji/wasm-clang (https://github.com/binji/llvm-project/releases/tag/wasm-bin-3)
This is extremely useful, as it allows bringing a modern compiler to many old systems, e.g. via wasm2c and https://github.com/turbolent/w2c2.
Ever since WASI SDK was released, I hoped that we could have a "self-hosting" build of it, i.e. WASI SDK compiled to WASI.
I "re-applied" Ben's changes on top of LLVM 15, the version that WASI SDK 19 uses. Unlike the original changes, I simply used the
__wasi__define, and did not change wasi libc / libcxx -- according to Ben, he faked threading support. Instead, I opted for also adjusting the code that relies on threading support and related data structures (mutex, conditional variables, etc.).Diff: turbolent/llvm-project@8dfdcc7...8e9c506
As you can see, there were not too many changes needed to get it to compile, however, the changes are hacky at times.
I hope that with the upcoming threading support of WASI / WASI SDK, it should be possible to re-enable much of the threading related code in LLVM.
I have not tested the resulting binaries of clang and wasm-ld too much, but they are able to compile a simple hello world program.
I'm opening this PR as a draft, as I would like to get some feedback and also this allows me to share the port with e.g. the llvmbox project.