[PATCH] D47589: [RISCV] Add codegen support for atomic load/stores with RV32A

[James Y Knight via Phabricator via llvm-commits]

jyknight added a comment.

In https://reviews.llvm.org/D47589#1119221, @jfb wrote:

> Can you refer to documentation that says so? I'm happy if that's the case, but I want to be really sure it is. Not just for compiler-rt, but for GCC as well (I've ping'd someone on that side to get more info). If so the @t.p.northover's patch fixing some alignment stuff is also something we want, and we'll want to update some documentation.


That is what GCC's LIbrary docs you referred to before say -- although I agree it's not as clear as it could be.

Starting with "All the optimized routines expect that the object will be properly aligned for a data type of the specified size." In this doc, "optimized routines" means the function names ending with a size, so `__atomic_load_4`, but not `__atomic_load`. Then it says: "The compiler will not map the generic routine to an optimized routine unless the alignment is correct." The clear implication of both those sentences together is that `__atomic_load` does _NOT_ require the object will be properly aligned.

The next question perhaps is whether `__atomic_load` *MUST* use a lock-free implementation when given suitably-aligned data.  The answer to that is the same as the answer to whether `__atomic_load_4` must, because "A lazy compiler may simply call the generic routine, bypassing the optimized versions" -- so they must both use the same atomicity mechanism.

And the answer for both is effectively "Yes if the runtime-detected CPU supports it", because you have the requirement that code built for a CPU without atomic instructions for a given size (and thus calling into libatomic for everything), must interoperate properly with code built for a newer CPU model that does support lock-free atomics of that size. (e.g. if I build one .so with -march=386 and another .so with -march=486, they must work together). That implies that __atomic_load and __atomic_load_4 *MUST* use native atomic ops in //at least// as many situations as the compiler could have emitted inline atomics for.


https://reviews.llvm.org/D47589