[llvm] [LangRef] No target-specific size limit for atomics (PR #136864)
Michael Kruse via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 28 08:29:50 PDT 2025
Meinersbur wrote:
The question is, what a Frontend should do. Let's say it needs a atomic of size 16:
1. Unconditionally emit an LLVM-IR cmpxchg instruction. With my undertanding of the current LangRef, this is illegal IR even if AtomicExpandPass would convert the illegal IR to legal IR.
2. Instantiate the TargetMachine and ask it for the supported atomic size. For Clang the discussion was that this would require LLVM_TARGETS_TO_BUILD to emit LLVM-IR for a specific architecture which was an unwelcome change.
3. Implement its own target-triple dependent lookup of for each target[^1].
4. If it is just "most targets" then the frontend still needs to know what those targets are. If it has to know itself, this is not that much different from the previous. If it is just a (non-normative) note then it would also still be illegal IR.
5. A middle ground would be "If target can support atomics of arbitrary size then atomic load/store/cmpxchg can be of any size. Otherwise, the size must be at most TargetLoweringBase::getMaxAtomicSizeInBitsSupported()". If it is not supported, usually frontends cannot just simply not emit an atomic. We would prefer it it emitted an error instead of crashing or emitting illegal IR, so we still would need a list of supported target triples in the frontend...
The frontend still needs to implement libcall fallbacks for cases such as non-constant sizes (this is what #134455 is doing). If due to compiler optimizations the argument becomes constant (e.g. because it is wrapped in a utility function that should work for any size), there currently is no way back to an atomic load/store/cmpxchg instruction. So ideally AtomicExpandPass would handle non-constant sizes/ordering flags as well.
[^1]: Clang has its own `TargetInfo` that contains a lot where IMHO the backend should be the source-source-of-truth. For Flang this means we may need to duplicate that info once more or also instantiate `TargetInfo` in addition to its own `TargetCharacteristics`. Maybe the [RFC](https://discourse.llvm.org/t/llvm-introduce-an-abi-lowering-library/84554) will help.
https://github.com/llvm/llvm-project/pull/136864
More information about the llvm-commits
mailing list