[llvm-dev] [cfe-dev] Adding sanity to the Atomics implementation

[Reid Kleckner via llvm-dev]

On Wed, Jan 27, 2016 at 11:55 AM, James Knight via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
> (Q: what about the implementation of
> __atomic_is_lock_free/__atomic_always_lock_free in clang? The clang
> frontend can't query target information from the llvm backend, can it? Is
> there some other way to expose the information of what sizes are supported
> by a backend so that the clang builtins -- the latter of which must be a
> C++ constant expression -- can also use it? Or...just continue duplicating
> the info in both places, as is done today...)
>

I think this here is the main challenge. The frontend (and std::atomic
implementations) need to know whether the target can perform an atomic
operation without locks, and they can't rely on the LLVM target being built
in for this information.

I think Clang should continue to duplicate this information, the same way
we duplicate target datalayout strings. Other than that, sure, we can let
LLVM expand IR operations to libcalls. I don't immediately see a problem
with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160128/20ba1bda/attachment.html>