whitequark wrote: @jyknight Thanks for the review! I will split the stubs off.
Regarding threading, there is an unfortunate combination of issues here: 1. The `wasm32-wasip1` target doesn't have e.g. `std::mutex` available at all. This makes it impossible to build LLVM and the amount of conditional compilation is such that (as far as I understand) it has no chance of being merged. 2. The `wasm32-wasip1-threads` target, with `-pthread` enabled, does have those primitives, but using this target causes the compiled executables to use shared memory (even if they don't spawn threads), which makes some downstream tools like jco [reject](https://github.com/bytecodealliance/jco/issues/470) such binaries even if they don't spawn threads. 3. In some cases (see LLD above), LLVM compiled without `LLVM_ENABLE_THREADS` would still statically link to thread spawning primitives, which would make the executables unusable on hosts which do not support threads (even if they support atomics and accept memories marked as shared). It wasn't clear to me initially what the way forward is, but it seems like it's not really feasible to conditionalize each use of `std::mutex` and instead WASI sysroots should provide a single-threaded implementation of synchronization primitives for embeddings which do not spawn threads, rather than placing this burden on code targeting Wasm. https://github.com/llvm/llvm-project/pull/92677 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
