[flang-commits] [flang] [llvm] [mlir] [OpenMPIRBuilder] Emit __atomic_load and __atomic_compare_exchange libcalls for complex types in atomic update (PR #92364)

[Michael Kruse via flang-commits]

Meinersbur wrote:

> I sent across this PR for review to request for suggestions on this only. Is it okay if Clang is also made dependent on the OpenMPIRBuilder for emitting `__atomic_compare_exchange`, when the two IRs are different? 

Clang shouldn't use OpenMPIRBuilder for non-OpenMP stuff. The approach would move [`AtomicInfo`](https://github.com/llvm/llvm-project/blob/9f449c34278191193f2f2cbc96c333548ad20238/clang/lib/CodeGen/CGAtomic.cpp#L30) (that is, the non-Clang specific parts of it) to LLVMFrontend which is then used by `OpenMPIRBuilder`.


> The main issue I faced was determining which of the two IRs (Clang codegen vs AtomicExpandPass) was the one we should try. I could not determine the same, so thought to send this initial PR once, and seek clarifications on the same.

The answer is both. Comments in CGAtomic justify why part is lowered there, part in `AtomicExpandPass`. 
Regarding lifetime markers, orienting towards what Clang does is probably less risky. `AtomicExpandPass` is used only at the end of the optimization pipeline, passes in-between may already have transformed the lifetime markers.
Take [IR Best Practices](https://llvm.org/docs/Frontend/PerformanceTips.html#ir-best-practices) into account:

> [...] it’s worth noting that the most mature frontend for LLVM is Clang. As a result, the further your IR gets from what Clang might emit, the less likely it is to be effectively optimized.

unless there is a reason not to.

https://github.com/llvm/llvm-project/pull/92364