[llvm-dev] Memory scope proposal

[Mehdi Amini via llvm-dev]

> 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