I see atomic.wait.i32 and atomic.notify.i32 in the spec -- if I try to use the intrinsic __builtin_wasm_atomic_wait_i32
clang blows up with: fatal error: error in backend: Cannot select: intrinsic %llvm.wasm.atomic.wait.i32.
What am I doing wrong?
Also, from reading the spec, it seems like these instructions will trap if called when the memory buffer is not a shared buffer (i.e. when threads aren't possible). Is this true?
At the wasm level, yes, wait on non-shared memory was changed to trap: https://github.com/WebAssembly/threads/pull/147
At the toolchain level, we used to have separate options for "what wasm spec features are available?" and "what threading model do you want the compiler to use?"
There was pushback from people who felt that there were too many options, so now we no longer have a way to configure these separately. Unfortunately, this means we no longer have a way to support wait
without enabling a muilti-threaded model, but WASI doesn't support the multi-threaded models
The trap piece makes sense (was just unfortunate, I was hoping to use wait to end up with a sleep() equivalent, regardless of threading model) -- but is the clang error just due to the compiler not being allowed to emit an atomic wait because it knows that the code doesn't have the multi-threaded model selected?
(I have a meeting in 2 minutes, but briefly here,) the error is that the backend doesn't think that the target has a wait instruction, so it doesn't know how to encode a wait intrinsic.
You can tell it that it has a wait instruction with -mthreads, but that has other side effects
Also, ideally clang should be diagnosing the "I don't know how to do that with the current target configuration" error, rather than letting the backend crash on it, but that's just for tidiness
makes sense, thanks!
Last updated: Nov 22 2024 at 17:03 UTC