> On Aug 30, 2016, at 5:53 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi, > > [Sorry for chiming in so late.] > > I understand why a straightforward metadata scheme won't work here, > but have you considered an alternate scheme that works in the > following way: > > - We add a MD node called !nosynch that lists a set of "domains" a > certain memory operation does *not* synchronize with. > > - Memory operations with !nosynch synchronize with memory operations > without any !nosynch metadata (so dropping !nosynch is safe).I’m not sure, but isn’t the synchscope id (or domains as you seem to call it) intended to change which instruction would be actually codegen? In which case I’m not sure dropping it is ever a good idea, even when it does not affect correctness it would dramatically affect performance. — Mehdi> > This will only work if your frontend knows, ahead of time, what the > possible set of synch-domains are, but it presumably already knows > that (otherwise how do you map domain names to integers)? > > The other disadvantage with the scheme above is that memory operations > on the "normal CPU heap" (pardon my GPU n00b-ness here :) ) will synch > with the memory operations with !nosynch metadata. However, we can > solve that by modeling the "normal CPU heap" as "!nosynch > !{!special_domain_a, !special_domain_b, ... all domains except > !cpu_heap_domain}". > > Thanks, > -- Sanjoy
Hi Mehdi, Mehdi Amini wrote: > I’m not sure, but isn’t the synchscope id (or domains as you seem to > call it) intended to change which instruction would be actually FYI, I don't know what the right term for this is. :) > codegen? > > In which case I’m not sure dropping it is ever a good idea, even > when it does not affect correctness it would dramatically affect > performance. Sure, that is a good reason to avoid a metadata based approach. I was just unconvinced by the current argument of (at least on the commit message) "it can't be done", because I think a scheme modeled after the !tbaa style metadata scheme has a chance of working. If the fundamental reason why we want a non-MD scheme is something other than "it can't be done", I'm fine with that. -- Sanjoy
> On Aug 31, 2016, at 12:14 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Mehdi, > > Mehdi Amini wrote: > > I’m not sure, but isn’t the synchscope id (or domains as you seem to > > call it) intended to change which instruction would be actually > > FYI, I don't know what the right term for this is. :) > > > codegen? > > > > In which case I’m not sure dropping it is ever a good idea, even > > when it does not affect correctness it would dramatically affect > > performance. > > Sure, that is a good reason to avoid a metadata based approach. I was > just unconvinced by the current argument of (at least on the commit > message) "it can't be done", because I think a scheme modeled after > the !tbaa style metadata scheme has a chance of working. If the > fundamental reason why we want a non-MD scheme is something other than > "it can't be done", I'm fine with that.My understanding is that (I leave the AMD folks (Tony?) correct this if I missed something): 1) we want to preserve the synchscope information because it is important for codegen. This is usually done with intrinsics in other backends 2) not doing with intrinsic would allow the optimizer to reason about the atomic operation within a single scope, but couldn’t assume anything across scope I don’t know enough to assert if 2 is compelling enough to have first class support in the IR for something that is so “opaque”. — Mehdi