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

[JF Bastien via Phabricator via llvm-commits]

jfb added a comment.

In https://reviews.llvm.org/D47589#1118192, @efriedma wrote:

> > Seems you're advocating that this patch (and the LangRef) follow the reality you'd like to have, not the one we actually have :-)
>
> My description matches the way GNU libatomic works in practice, as far as I know.  (compiler-rt's implementation is incomplete and broken in other ways anyway; see https://reviews.llvm.org/D47606.)


I can't look at the implementation, but the docs are kinda unclear: https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy
If we intend to make this guarantee official it would be nice for our GCC friends to do the same. Will send a ping.

>> So I'll re-iterate: is the alignment check a documented guarantee that __atomic_* functions must provide, in all of their implementations?
> 
> The specialized forms (`__atomic_load_8` etc.) assume natural alignment, but the forms which take a size argument check alignment.  This is why `__atomic_is_lock_free` has a pointer argument. See  https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary .

That page says:

> All the optimized routines expect that the object will be properly aligned for a data type of the specified size. Results are undefined for objects not properly aligned if they are invoked directly. (ie, may or may not work as expected). The compiler will not map the generic routine to an optimized routine unless the alignment is correct.

Is that not the case?

My understanding was that `__atomic_is_lock_free` took a pointer argument because of C's specification, but C later backtracked on alignment (because it was another of their changes which C++ didn't have) and now ignores it. >From the docs it looks like `__atomic_is_lock_free` indeed guarantees it'll look at alignment. I'm not sure about the actual atomic functions though.


https://reviews.llvm.org/D47589