search for: d21723

Hi, I have updated the review here: https://reviews.llvm.org/D21723 As Sameer pointed out, the motivation is: In OpenCL 2.x, two atomic operations on the same atomic object need to have the same scope to prevent a data race. This derives from the definition of "inclusive scope" in OpenCL 2.x. Encoding OpenCL 2.x scope as metadata in LLVM IR would be a pr...

...meer Sahasrabuddhe; Philip Reames > Cc: Mehdi Amini; Liu, Yaxun (Sam); Ke Bai; Mekhanoshin, Stanislav; Sumner, Brian; llvm-dev at lists.llvm.org; Tye, Tony > Subject: RE: [llvm-dev] Memory scope proposal > > Hi, > > I have updated the review here: > https://reviews.llvm.org/D21723 <https://reviews.llvm.org/D21723> > > As Sameer pointed out, the motivation is: > In OpenCL 2.x, two atomic operations on the same atomic object need to have the same scope to prevent a data race. This derives from the definition of "inclusive scope" in OpenCL 2.x. Encodi...

...t is not primary, but in this case it seems that the atomicity, memory ordering and memory scope are all equally primary information that characterize the semantics of memory instructions. We have posted reviews that implement the proposal and invite everyone to discuss it: http://reviews.llvm.org/D21723 http://reviews.llvm.org/D21724 Thank you, Konstantin -----Original Message----- From: Tom Stellard [mailto:tom at stellard.net] Sent: Wednesday, June 22, 2016 4:51 PM To: Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> Cc: Mehdi Amini <mehdi.amini at apple.com>; Liu, Yaxun (Sam)...

...is case it seems that the atomicity, memory ordering and memory scope are all equally primary information that characterize the semantics of memory instructions. >> >> We have posted reviews that implement the proposal and invite everyone to discuss it: >> http://reviews.llvm.org/D21723 >> http://reviews.llvm.org/D21724 > > It seems you’re going back to integer, which I don’t really like for reasons mentioned earlier in this thread, and that I don’t feel you addressed here. > > — > Mehdi > > > > >> >> Thank you, >> Konstan...

...hin, Stanislav; Sumner, Brian; llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; Tye, Tony >>> Subject: RE: [llvm-dev] Memory scope proposal >>> >>> Hi, >>> >>> I have updated the review here: >>> https://reviews.llvm.org/D21723 <https://reviews.llvm.org/D21723> >>> >>> As Sameer pointed out, the motivation is: >>> In OpenCL 2.x, two atomic operations on the same atomic object need to have the same scope to prevent a data race. This derives from the definition of "inclusive scope&quo...

Hi all, On 02.05.2016 17:46, Tom Stellard via llvm-dev wrote: >> Why not going with a metadata attachment directly and kill the "singlethread" keyword? Something like: >> >Something like: >> > >> > cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, !memory.scope{!42} >> > cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3,

On Wed, Aug 31, 2016 at 12:23:34PM -0700, Justin Lebar via llvm-dev wrote: > > Some optimizations that are related to a single thread could be done without needing to know the actual memory scope. > > Right, it's clear to me that there exist optimizations that you cannot > do if we model these ops as target-specific intrinsics. > > But what I think Mehdi and I were