WASI support

[turbolent]

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.

[abrown]

This is pretty cool!

[abrown]

For the threads-related code, you might need to use the wasm32-wasi-threads target and the wasi-sdk-20+threads pre-release.

[sbc100]

Nice!

If possible, could you share a link that shows the changes to upstream llvm that were required?

(edit: Doh! I saw you did that already right in the PR description, sorry).

[sbc100]

I think we can/should probably land this hunk separately and without delay since I think it would speed up our builds.

[turbolent]

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.

[sbc100]

They are not needed as far as I know, we don't use any of those binaries.

[sbc100]

Can you rebase this now that #309 has landed?

[sbc100]

If possible, could you share a link that shows the changes to upstream llvm that were required?

Doh! I saw you did that already right in the PR description, sorry.

[sunny-g]

I'm having trouble re-producing, but a thought occurred to me - could wasix-libc obviate the need to make changes to LLVM?

[sunfishcode]

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 #ifndef __wasi__ to something like #ifndef _REENTRANT, because as @abrown mentions above, WASI doesn't always mean no threads.

[turbolent]

@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

[sbc100]

@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.

[theoparis]

I tried to update this to LLVM 18/HEAD 🚀
Edit: It turns out the mutex header needs to be fixed for it to be properly upstreamed to LLVM.

[whitequark]

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.

[turbolent]

@whitequark Great work properly "upstreaming" this! 👏

[whitequark]

Thanks. Feel free to chime in on the RFC or the LLVM PR.

[whitequark]

From the RFC thread:

AaronBallman

Nope, not a deal-breaker at all! In fact, I think this strikes a really good balance between LLVM community resources and your needs. Thank you for verifying!

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.

[whitequark]

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.

LLVM already has the LLVM_ENABLE_THREADS switch so I think it shouldn't be too controversial to expand its scope to cover the entire build.