[llvm-dev] Adding sanity to the Atomics implementation

[JF Bastien via llvm-dev]

On Sun, Jan 31, 2016 at 12:42 AM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> ----- Original Message -----
> > From: "Ben via llvm-dev Craig" <llvm-dev at lists.llvm.org>
> > To: llvm-dev at lists.llvm.org
> > Sent: Thursday, January 28, 2016 9:41:06 AM
> > Subject: Re: [llvm-dev] Adding sanity to the Atomics implementation
> >
> >
> > I don't have much of substance to add, but I will say that I like the
> > proposal (I too prefer Alternative A).
>
> I also prefer alternative A.
>

Same here: +1 to A.

it makes it easier to support virtual ISAs. For targets such as WebAssembly
we don't know ahead-of time what's atomic but we make certain assumptions
(e.g. atomic_flag has to be sufficiently sized to be lock-free). As David
pointed out this means that _Atomic and std::atomic have to be
"sufficiently sized" e.g. sizeof(T) == sizeof(std::atomic<T>) isn't
guaranteed (the guarantee is also there for other academic reasons, but I
don't think they matter in this case).

Another consideration: we want to get the atomic optimizations, which
option B would forbid because the middle-end would see libcalls instead of
atomics.

Also, I'd like LLVM to eventually be able to patch code at load-time and
transform maybe-lock-free operations into the proper instruction or libcall.

Related to always lock-free: wg21.link/n4509
Note that C has macros that return never / sometimes / always lock-free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/564bb00e/attachment.html>