[PATCH] D136525: [M68k] Add codegen pattern for atomic load / store

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

In D136525#3901614 <https://reviews.llvm.org/D136525#3901614>, @0x59616e wrote:

> Conclusion 1: According to 1 & 2 & 3,  if we don't have `CAS` support, we have to transform the `atomic_load` / `atomic_store` to `__atomic_*` library calls, instead of normal `load` / `store`, to avoid the mixture of lock-free instruction & non-lock-free library calls.
>
> Conslusion 2: According to 1 & 2 & 3, If we have `CAS` support, we can just simply lower `atomic_load` / `atomic_store` / `atomic_compare_and_swap` to the native instruction, and expand the `atomic_rmw` to either `atomic_compare_and_swap` or `__sync_*` calls --- which all of them are lock-free.
>
> Right ?

Right.  You want to call `setMaxAtomicSizeInBitsSupported(32)` on targets that have 32-bit CAS.

If `__sync_*` is available for a given bitwidth, it counts as "having" CAS support.  `setOperationAction(ISD::ATOMIC_CMP_SWAP, MVT::i32, LibCall);` will tell the legalizer to generate the call for you.

In D136525#3906658 <https://reviews.llvm.org/D136525#3906658>, @myhsu wrote:

> And I think `__sync` is preferable here because it makes more sense to conditionally lower cmpxchg to libcall based on target CPU in the backend , compared to detecting target CPU in an IR Pass.

We don't really make the distinction between "IR" passes vs. "CodeGen" passes.  We draw the line between "optimization" passes (which are controlled by the frontend) and "backend" passes (which are directly controlled by the target in its implementation of TargetPassConfig).  Some "backend" passes run on IR simply because it's convenient: LLVM IR is simpler to deal with (especially given the limitations of SelectionDAG).


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

https://reviews.llvm.org/D136525