[PATCH] D47553: Add TargetLowering::shouldExpandAtomicToLibCall and query it from AtomicExpandPass

[James Y Knight via Phabricator via llvm-commits]

jyknight added a comment.

In https://reviews.llvm.org/D47553#1117630, @asb wrote:

> I'm going to un-abandon this patch. This hook is still helpful in order to e.g. lower to __atomic libcalls for all 8 and 16-bit operations but not 32-bit. This seems acceptable based on the linked GCC and LLVM docs, but isn't possible with the current MaxSizeInBitsSupported. Am I missing any problems with that strategy?
>
> It seems GCC RISC-V will emit `__atomic_*` libcalls for 8 and 16-bit operations other than load/store even with -march=rv32ia. The immediate response in the linked GCC bug report is that perhaps that fine if the RISC-V version of these sub-word atomics is guaranteed to be lock-free (which apparently is the case for libatomic compiled for rv32ia). If this is confirmed, it would give a case where intermixing is safe. I don't know how reasonable it is to declare `__atomic_*` libcalls are lock-free if compiled with support for the A extension - if you have views please do jump on the GCC bug report thread <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005>.


No...while it shouldn't be _broken_, it makes no sense to do so. If you can do 32-bit operations atomically, you can of course do the same for 8 and 16.


https://reviews.llvm.org/D47553