Hi Szabolcs, > On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy <szabolcs.n...@arm.com> wrote: > > On 17/11/16 20:12, Bin Fan wrote: >> >> Although this ABI specification specifies that 16-byte properly aligned >> atomics are inlineable on platforms >> supporting cmpxchg16b, we document the caveats here for further discussion. >> If we decide to change the >> inlineable attribute for those atomics, then this ABI, the compiler and the >> runtime implementation should be >> updated together at the same time. >> >> >> The compiler and runtime need to check the availability of cmpxchg16b to >> implement this ABI specification. >> Here is how it would work: The compiler can get the information either from >> the compiler flags or by >> inquiring the hardware capabilities. When the information is not available, >> the compiler should assume that >> cmpxchg16b instruction is not supported. The runtime library implementation >> can also query the hardware >> compatibility and choose the implementation at runtime. Assuming the user >> provides correct compiler options > > with this abi the runtime implementation *must* query the hardware > (because there might be inlined cmpxchg16b in use in another module > on a hardware that supports it and the runtime must be able to sync > with it).
Thanks for the comment. Yes, the ABI requires libatomic must query the hardware. This is necessary if we want the compiler to generate inlined code for 16-byte atomics. Note that this particular issue only affects x86. I notice GCC already have a few builtins declared in cpuid.h. The functions are x86 specific. So couldn’t the query be done by those functions? > > currently gcc libatomic does not guarantee this which is dangerously > broken: if gcc is configured with --disable-gnu-indirect-function > (or on targets without ifunc support: solaris, bsd, android, musl,..) > the compiler may inline cmpxchg16b in one translation unit but use > incompatible runtime function in another. > > there is PR 70191 but this issue has wider scope. This issue was actually found by us while we are working on the ABI draft. So we filed the bug and we think it should be fixed. Compiler inlining 16-byte atomics has other issues as noted in the ABI draft. So the alternative is stop inlining those atomics, but that would need a compiler fix. Thanks, - Bin > >> and the inquiry returns the correct information, on a platform that supports >> cmpxchg16b, the code generated >> by the compiler will both use cmpxchg16b; on a platform that does not >> support cmpxchg16b, the code generated >> by the compiler, including the code generated for a generic platform, always >> call the support function, so >> there is no compatibility problem. >
