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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to