[PATCH] D49396: [WebAssembly] Support for atomic.wait / atomic.wake builtins

[Derek Schuff via Phabricator via cfe-commits]

dschuff accepted this revision.
dschuff added inline comments.
This revision is now accepted and ready to land.


================
Comment at: include/clang/Basic/BuiltinsWebAssembly.def:38
+// Atomic wait and wake.
+BUILTIN(__builtin_wasm_atomic_wait_i32, "Uii*iLLi", "n")
+BUILTIN(__builtin_wasm_atomic_wait_i64, "UiLLi*LLiLLi", "n")
----------------
aheejin wrote:
> dschuff wrote:
> > So this means that the signature is basically `unsigned int __builtin_wasm_atomic_wait_i32(int *, int, long long)`? We should maybe make it `int __builtin_wasm_atomic_wait_i32(const unsigned char *, int, unsigned long long)`. Returning int so that you could define a C enum with the possible return values and compare without type coercion; unsigned char * so that it aliases with everything (i.e. a byte ptr), and unsigned long long since a negative relative timeout isn't meaningful(?). Not sure whether we should use int or unsigned int as the expected value, can't think of any particular reason right now to use one or the other.
> > 
> > Likewise with the other signatures.
> > Returning int so that you could define a C enum with the possible return values and compare without type coercion;
> Done.
> 
> > unsigned char * so that it aliases with everything (i.e. a byte ptr),
> From this pointer a value will be loaded and compared with the expected value, which is an int. Shouldn't this be an int pointer then? Not sure why it should alias with a byte ptr.
> 
> > and unsigned long long since a negative relative timeout isn't meaningful(?).
> [[ https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md#wait | Timeouts can be negative ]], in which case it never expires. The wake count of `atomics.wake` builtin can be negative too, in which case it waits for all waiters.
> 
> > Not sure whether we should use int or unsigned int as the expected value, can't think of any particular reason right now to use one or the other.
> We didn't impose any restrictions other than it is an int in the spec, so I think it should be a (signed) int?
Oh you're right, I misread the spec. So int * and signed timeout is fine. For the expected value (and the pointer type) it could still be either signed or unsigned because at the wasm level there's no distinction. but signed int seems fine as it is.


Repository:
  rC Clang

https://reviews.llvm.org/D49396