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). 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. > 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.
