[cfe-dev] atomic intrinsics

[John McCall]

On Oct 7, 2010, at 5:30 PM, Howard Hinnant wrote:
> I see what you mean.  I'll mention this in the design doc.  I believe it will be an issue for any design we choose (A, B, or C).


After some thought, I think I personally prefer proposal A, slightly modified such that __atomic_is_lock_free is a pseudofunction like __is_pod().  The builtins have exactly those names and are "overloaded";  memory ordering parameters are required to be constant expressions but not necessarily literals.  Arguments not of fundamental type, or not exactly matching a permitted type for the intrinsic, are not required to be supported by the implementation (so calling swap with a long* and an int, or a Base** and a Derived*, or a ConvertibleToIntPtr and a ConvertibleToInt, may or may not have sensible results).

I'm not worried about the amount of work this imposes on the compiler writers because (1) most of that work is actually pretty much copy-and-paste and (2) it's all required for an ABI-conformant implementation anyway.  So the fact that proposal B nicely adapts as the compiler incrementally improves support is not interesting to me because the compiler isn't actually permitted to incrementally improve support. :)  Also I really don't like the idea of this library requiring almost a hundred new differently-named builtins.

This doesn't strictly matter for you, but we would implement this in Clang by having the frontend do the ABI-compliant lowerings for the locking implementations and then emitting everything that can be done lock-free as an LLVM intrinsic call.

Anyway, just my vote.

John.