[RFC] Building LLVM for WebAssembly

LLVM Project
41

If you open an issue on wasi-sdk we can find out.

Ah, I should add this patch to my PR. Thanks for investigating!

42

Shouldnā€™t that be gated by thread usage instead of being wasm or not?

43

Iā€™ve gated it by thread usage.

44

Iā€™ve changed the build so that it compiles everything into the single LLVM driver binary (the llvm driver). This produces a complete toolchain less than 23 MB in size! Unfortunately, for some reason clang built this way doesnā€™t seem to run cc1 in-process, or perhaps it just doesnā€™t show it this way with -###; I havenā€™t investigated closely.

45

The configure time cost for the API checks is unfortunate, but not cost prohibitive right?

The piecemeal adoption of the APIs as originally proposed (i.e. HAVE_? checks) could improve the codebase for portability. While some of the semantics cannot be provided on all platforms, it might make it easier to provide equivalences across platforms for subsets with different ways to write the necessary operation. It could even possibly help smoothen some of the windows/Unix differences (e.g. LLVM_ON_UNIX) which often is confusing with MinGW and cygwin in the mix.

46

I am just speculating here, but maybe the wasi driver ends up generating more than one action? We artificially limit cc1 to one running action in-process, because clang leaks its memory on exit (see -disable-free). It was judged that several actions would require more testing, and I never got around to land that. However the in-process branch Iā€™ve mentioned above can run any number of actions in-process by disabling -disable-free for all in-process actions. You can maybe try doing that for wasi specifically?

47

One other point if you do that: LLD doesnā€™t have a -disable-free flag, it always leaks its memory and thereā€™s no flag to disable that behavior. But it could be added easily (early in lld.cpp). But maybe tail actions can keep -disable-free active.

48

Iā€™m quite late to this party (and Iā€™ve only skimmed the discussion) but just BTW/FYI Iā€™ve been building mlir+llvm->wasi nightlies for about a month (with releases being published here; ctrl+f mlir_wasm). I donā€™t have much to add, since as I said I havenā€™t caught up yet on the prior discussion, but also itā€™s clear youā€™ve solved more blockers than I did.

One interesting/surprising thing (for me, personally) was how much smaller the resulting binaries (e.g., mlir-opt) ended up being (~26MB), which turned out to be the case because wasm doesnā€™t (by default) named symbols for functions (instead using an index into a function array).

Anyway I guess just here to say I think this is great and Iā€™ll be watching/reading.

49

Thereā€™s a significant difference between the two builds: mine is pure-Wasm, while yours as far as I can tell is Emscripten with embind. Both have their advantages; my intended application doesnā€™t make it feasible to use Emscripten, which is why Iā€™m going for a pure-Wasm/WASI build.

1 Like
50

Thereā€™s a significant difference between the two builds

Yea it wasnā€™t clear what the exact differences were but it was clear there were significant differences. I didnā€™t mean to imply that I had solved many of the problems youā€™ve solved.

Emscripten with embind

I do have -lembind there but Iā€™m not currently using any of the embind facilities
(Iā€™m actually not using that distrbution at all but when I do, I donā€™t plan to use embind, so thatā€™s just a stray flag).

1 Like
51

Any updates on this RFC/the corresponding PR?
I could also help with implementation / replying to review if that would help getting this merged :slight_smile:

52

We are waiting for a resolution on this wasi-libc PR.

53

The wasi-libc PR has been merged, so the door is now open for LLVM to be tested on nightly wasi-sdk. Iā€™m not sure if Iā€™ll have time for it this year. Also, the LLVM changes probably canā€™t be merged until there is a new wasi-sdk release.

3 Likes
54

LLVM was apparently already tested with the PR, and now another PR, this time for libc++ integration in wasi-libc, is the one this effort is blocked on.

4 Likes
55

Any updates on this? It would be really cool if we could use LLVM from WebAssembly!

1 Like
56

Iā€™ve filed Using libc++ with the "emulated pthreads" mode Ā· Issue #546 Ā· WebAssembly/wasi-sdk Ā· GitHub which should hopefully be the last piece of the puzzle required to enable upstream LLVM be built with WASI SDK. Once it is resolved (hopefully in the next WASI SDK release) it will be possible, at last, to have an upstream port of Clang to WASI.

5 Likes
57

Iā€™ve submitted PRs to enable libc++ to be built with concurrency primitives for THREAD_MODEL=single:

These are considered release blockers for wasi-sdk-26 and wasi-sdk-27, so the support should be available shortly.

3 Likes
58

I saw that both PRs got merged, and the latest SDK release ( Release wasi-sdk-26 Ā· WebAssembly/wasi-sdk Ā· GitHub ) includes the PRs. In Enable pthreads in libc++ for `THREAD_MODEL=single` by whitequark Ā· Pull Request #548 Ā· WebAssembly/wasi-sdk Ā· GitHub you mentioned that you successfully built Clang, amazing, well done!

Could you please share a few instructions on how to reproduce this? Iā€™d love to get a build and replace the outdated hack I have in w2c2. What version of Clang did you build, and how?

59

Right now Iā€™m too sick to run the entire build end to end it, but GitHub - YoWASP/clang at npm should contain a (very work-in-progress, and falling short of the quality of stuff I usually release) script for building Clang. It should either work (itā€™s based on stuff that I used to verify wasi-sdk changes) or be very close to working. Let me know if you hit any issues.

1 Like
60

Thank you for sharing the instructions, much appreciated! Hope you feel better soon!