[llvm-dev] Adding sanity to the Atomics implementation

[Philip Reames via llvm-dev]

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.
Also, +1.
>
> 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160201/5ae65890/attachment.html>