[llvm-dev] Adding sanity to the Atomics implementation
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 1 12:27:13 PST 2016
On 02/01/2016 06:39 AM, JF Bastien via llvm-dev wrote:
> On Sun, Jan 31, 2016 at 12:42 AM, Hal Finkel via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> ----- Original Message -----
> > From: "Ben via llvm-dev Craig" <llvm-dev at lists.llvm.org
> <mailto:llvm-dev at lists.llvm.org>>
> > To: llvm-dev at lists.llvm.org <mailto: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.
Strongly agreed with this part.
> 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 <http://wg21.link/n4509>
> Note that C has macros that return never / sometimes / always lock-free.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev