[cfe-dev] Why does __atomic generate IR calls when __sync generates atomicrmw?

[David Chisnall via cfe-dev]

On 23 Nov 2015, at 21:37, Craig, Ben via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Why is a function call generated in clang?  Why don't we let LLVM choose whether to emit a function call or inline assembly in these cases?

The short answer is: that was easiest to implement and various bits of atomic support were done in a bit of a rush.  It’s not the right design decision, because it prevents the optimisers working on these things.

If someone has time to work on this, then it would be much better to:

- Extend atomic compare and exchange to work natively on floating point and pointer types (remove the bitcasts to integers - they’re problematic for various things in both optimisers and code generation)

- Modify clang to always emit the atomicrmw or cmpxchg instructions.

- Add a parameterisable pre-codegen lowering pass that will transform them into calls to library functions if not supported by the target.

> Another reason I care about this is because some atomic operations aren't directly supported by my hardware ( 4 byte and 8 byte atomics are directly supported, 1 byte and 2 byte atomics are not).


If you look in the MIPS back end, you’ll see exactly the same thing.  32-bit and 64-bit ll/sc is natively supported, the rest must be turned into an ll/sc loop with a mask.

David