[PATCH] D120026: [ARM] Fix ARM backend to correctly use atomic expansion routines.

Mon Jul 25 06:32:54 PDT 2022

nikic added a comment.

In D120026#3674604 <https://reviews.llvm.org/D120026#3674604>, @efriedma wrote:

> I see two possible approaches to restore the functionality you want.
>
> One, you could add a target feature that says "I have 32-bit (or 64-bit) atomics".  That would override the normal rule for setMaxAtomicSizeInBitsSupported.  The target environment would be expected to provide whatever `__sync_*` functions are necessary.  If you don't actually use any atomic operations that require CAS, you won't see any calls, so everything works even if the functions don't actually exist.  (Or it's possible to write an operating system that implements lock-free CAS on Cortex-M0, the same way the Linux kernel implements atomics on old ARM cores.)

I think this is the solution we want. I've put up https://reviews.llvm.org/D130480 to implement this.

> Two, you could relax the constraint that atomic load/store are required to be atomic with respect to cmpxchg.  We can add a value to syncscope to represent this.  This would allow mixing code that uses load-store atomics with code that requires "real" atomics.
>
> That said, I'm not sure how you use load-store atomics in practice. I mean, I guess you can use Dekker's alogorithm, or some kinds of lock-free queues, but that seems a bit exotic.  Or do you use some sort of lock implemented by disabling interrupts?

Some use cases are mentioned starting from here: https://github.com/rust-lang/rust/issues/99668#issuecomment-1193417939 So it seems to be mostly about synchronization with interrupt handlers, lock-free spsc queues, as well as ability to use atomics as safe mutable globals (a rust-specific issue). And yes, disabling interrupts for critical sections seems to be common practice in this context as well.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120026/new/

https://reviews.llvm.org/D120026