jyknight added a comment. In D71726#2207700 <https://reviews.llvm.org/D71726#2207700>, @yaxunl wrote:
> clang does not always emit atomic instructions for atomic builtins. Clang may > emit lib calls for atomic builtins. Basically clang checks target info about > max atomic inline width and if the desired atomic operation exceeds the > supported atomic inline width, clang will emit lib calls for atomic builtins. > The rationale is that the lib calls may be faster than the IR generated by > the LLVM pass. This behavior has long existed and it also applies to fp > atomics. I don't think emitting lib calls for atomic builtins is a bug. > However, this does introduce the issue about whether the library functions > for atomics are available for a specific target. As I said, only the target > owners have the answer and therefore I introduced the target hook. The LLVM AtomicExpandPass is _also_ introducing libcalls (or cmpxchg loops), as is appropriate for a given target. We currently, redundantly, support the same thing in two places. It's a long-term goal of mine to simplify the atomics code in clang, by deferring more of it to LLVM, but some prerequisites (e.g. supporting misaligned atomicrmw) are not yet in place. The intent is that it is always valid to emit the LLVM atomic IR, and it will be transformed into whatever is best on a given target. As such, there's no reason to restrict these clang intrinsics. Yes, there are no generically available libcalls for atomic float math -- but that's okay -- let LLVM handle transform into a cmpxchg loop when required. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71726/new/ https://reviews.llvm.org/D71726 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
