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

Heejin Ahn via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jul 31 18:05:55 PDT 2018


aheejin added inline comments.


================
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")
----------------
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?


Repository:
  rC Clang

https://reviews.llvm.org/D49396





More information about the cfe-commits mailing list