similar to: [LLVMdev] [RFC][PATCH][OPENCL] synchronization scopes redux

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.

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 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

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: > >

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

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

Hi all, 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 discussion before and it can be found here:

On 1/9/2015 4:14 AM, Chandler Carruth wrote: > On Wed, Jan 7, 2015 at 8:03 PM, Sahasrabuddhe, Sameer > <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> > wrote: > > Here's what this looks like to me: > > 1. LLVM text format will use string symbols for memory scopes, > and not numbers. The set of strings is target

On 1/7/2015 9:42 AM, Chandler Carruth wrote: > I think it is significantly more friendly (and easier to debug > mistakes) if the textual IR uses human readable names. We already have > a hard time due to the totally opaque nature of address spaces -- > there are magical address spaces for segment stuff in x86. > > The strings are only opaque to the target-independent

> 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

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

> 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

On Tue, Jan 13, 2015 at 10:27 PM, Sameer Sahasrabuddhe < sameer.sahasrabuddhe at amd.com> wrote: > Ping! We need to close on whether everyone is convinced that symbolic > memory scopes have a significant advantage over opaque numbers. Either of > them will be examined by optimizations using a target-implemented API. I > personally don't think that readability in the LLVM

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

Copying #5 here for reference: > 5. Possibly add the following constraint on memory scopes: "The scope > represented by a larger value is nested inside (is a proper subset > of) the scope represented by a smaller value." This would also imply > that the value used for single-thread scope must be the largest > value used by the target. > This constraint

> 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