rjmccall 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.
If we want the frontend to emit an error when the target doesn't support
library-based atomics, that seems fine, but there's no reason to only do so for
floating-point types. That is, we should have a TargetInfo method that asks
whether atomics at a given size and alignment are supported at all, similar to
what we have for "builtin" (lock-free) atomics, and we should check it for all
the atomic types and operations.
Actually, maybe we should take the existing hook and have it return one of {
LockFree, Library, Unsupported }.
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
