similar to: Memory scope proposal

Ke, I'll be the bearer of bad news here. The radio silence this proposal has gotten probably means there is not enough interest in the community in this proposal to see it land. One concern I have with the current proposal is that the optimization value of these scopes is not clear to me. Is it only the backend which is expected to support optimizations over these scopes? Or are you

> On Apr 18, 2016, at 9:12 AM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Here is the initial proposal with some formatting fixed: > > Currently, the LLVM IR uses a binary value (SingleThread/CrossThread) to > represent synchronization scope on atomic instructions. We would like to > enhance the representation of memory scopes in LLVM IR to allow

​​ Dear all, Here is the plain text version of the proposal: Currently, the LLVM IR uses a binary value (SingleThread/CrossThread) to represent synchronization scope on atomic instructions. We would like to enhance the representation of memory scopes in LLVM IR to allow more values than just the current two. The intention of this email is to invite comments on our proposal. There are some

Hi all, Attached is a sequence of patches that changes the IR to support more than two synchronization scopes. This is still a work in progress, and these patches are only meant to start a more detailed discussion on the way forward. One big issue is the absence of any backend that actually makes use of intermediate synchronization scopes. This work is meant to be just one part of the

I've not had a good chance to look at the patches in detail, but just to clarify one point: I don't really care whether we number things going up or down from single threaded to "every thread". I just think it makes sense to expose them in the in-memory IR interface as an enum with a particular ordering so that code can use the obvious sorts of tests for comparing two orderings

> On Nov 18, 2014, at 2:35 PM, Chandler Carruth <chandlerc at google.com> wrote: > > > On Fri, Nov 14, 2014 at 1:09 PM, Sahasrabuddhe, Sameer <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> wrote: > 1. Update the synchronization scope field in atomic instructions from a > single bit to a wider field, say 32-bit unsigned integer.

> On Aug 17, 2016, at 2:08 PM, Zhuravlyov, Konstantin <Konstantin.Zhuravlyov at amd.com> 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

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 problem because there cannot be a

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use

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,

We believe that it would be best that this is added to the LLVM IR atomic memory instruction as fields on atomic instructions rather than using meta data. The reasoning is that this information is similar to other information that is represented as instruction fields. For example, the indication that memory operations are atomic rather than non-atomic, the memory ordering of atomics, and whether

On 11/19/2014 4:05 AM, Chandler Carruth wrote: > > On Fri, Nov 14, 2014 at 1:09 PM, Sahasrabuddhe, Sameer > <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> > wrote: > > 1. Update the synchronization scope field in atomic instructions > from a > single bit to a wider field, say 32-bit unsigned integer. > > > I

Hi Sameer, > On Jan 5, 2015, at 4:51 AM, Sahasrabuddhe, Sameer <Sameer.Sahasrabuddhe at amd.com> wrote: > > Right. The second version of my patches fixes the bitcode encoding. But now I see another potential problem with future bitcode if we require an ordering on the scopes. What happens when a backend later introduces a new scope that goes into the middle of the order? If they

On 1/6/2015 1:01 PM, Chandler Carruth wrote: > > On Mon, Jan 5, 2015 at 10:51 PM, Owen Anderson <resistor at mac.com > <mailto:resistor at mac.com>> wrote: > > Hi Sameer, > > > On Jan 5, 2015, at 4:51 AM, Sahasrabuddhe, Sameer > <Sameer.Sahasrabuddhe at amd.com > <mailto:Sameer.Sahasrabuddhe at amd.com>> wrote: > >

Hi Tim, On 20 November 2017 at 16:41, Tim Northover <t.p.northover at gmail.com> wrote: > There are only a couple of valid uses for volatile these days Do you mean volatile used alone or also the combination 'atomic volatile'? It think that 'atomic volatile' is very useful. Consider following pseudo-code examples, where all loads and stores are atomic (with some memory

> On Aug 21, 2016, at 11:14 AM, Philip Reames <listmail at philipreames.com> wrote: > > On 08/17/2016 03:05 PM, Mehdi Amini wrote: >> >>> On Aug 17, 2016, at 2:08 PM, Zhuravlyov, Konstantin <Konstantin.Zhuravlyov at amd.com <mailto:Konstantin.Zhuravlyov at amd.com>> wrote: >>> >>> >Why not going with a metadata attachment directly

On 1/7/2015 8:59 AM, Chandler Carruth wrote: > > Essentially, I think target-independent optimizations are still > attractive, but we might want to just force them to go through an > actual target-implemented API to interpret the scopes rather than > making the interpretation work from first principles. I just worry > that the targets are going to be too different and we may

Thanks for your help John... Yup, I looked at Local.cpp even before I fired off my question to the mailing list. Take a peek here at line 464: https://github.com/llvm-mirror/poolalloc/blob/master/lib/DSA/Local.cpp Based on my understanding of this line, if AtomicCmpXchgInst does not return a pointer type, nothing gets merged. And in the example I posted, a pointer value is indeed not returned

On 11/15/2014 12:08 AM, Tom Stellard wrote: > Can you send a plain-text version of this email. It's easier to read > and reply to. Sorry about that! Here's the plain text (I hope!): Hi all, OpenCL 2.0 introduced the notion of memory scope in atomic operations to global memory. These scopes are a hint to the underlying platform to optimize how synchronization is achieved. HSAIL