[LLVMdev] Loads moving across barriers

[Hal Finkel]

----- Original Message -----
> 
> 
> Sent from my iPhone
> 
> > On Nov 8, 2013, at 6:32 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> > 
> > ----- Original Message -----
> >> Hi Matt,
> >> 
> >> On Nov 8, 2013, at 1:14 PM, Matt Arsenault
> >> <Matthew.Arsenault at amd.com> wrote:
> >> 
> >>> Both of these I think sort of went in the wrong direction and
> >>> talked specifically about the semantics of the atomic
> >>> instructions
> >>> (fence in particular), which isn't the real question. Is noalias
> >>> supposed to mean that no other thread can also have a copy of the
> >>> pointer it also modifies? My guess at what was happening is that
> >>> since the parameter is noalias, the assumption is there is no
> >>> possible way for the side-effecting function to modify the
> >>> pointer. The second thread brings up an ambiguity in the C spec
> >>> about how restrict is supposed to be interpreted in the presense
> >>> of multiple threads. OpenCL still has restrict, but unless this
> >>> is
> >>> supposed to work, it is pretty close to useless.
> >> 
> >> I checked the OpenCL specification, and it doesn’t give any clear
> >> definition of restrict beyond implicitly importing what C99 says.
> >> That said, I think it’s is pretty clearly undesirable behavior for
> >> CL, even if it may (or may not) be technically permitted by the C
> >> specification.  I’d be in favor of clarifying our definition of
> >> noalias to disallow this transformation.
> > 
> > So we're specifically talking about intrinsics tagged as having
> > unmodeled side effects? Or arbitrary functions?
> 
> Arbitrary functions calls can contain barriers ( in CL) or thread
> joins (in C), so I think the same reasoning had to apply to them as
> well.

Right; in general, I think this is a bad idea. I certainly would not want to apply this logic in general because it will really hurt performance. The transformation really should be safe -- at least in the context of C semantics -- the barrier should not need to synchronize data pointed to by the noalias pointer because no other thread should be accessing data though an aliasing pointer while the function in question is executing (the guarantee noalias makes to the compiler is that it can see all relevant aliasing pointers).

OpenCL is a bit of a different story, perhaps, because of its implicit data-parallel semantics. However, it is also a closed environment (as far as I know). To deal with the problem of arbitrary functions containing barriers, you could add a function attribute and then propagate it in the FunctionAttrs pass.

 -Hal

> 
> -Owen
> 
> 
> > -Hal
> > 
> >> 
> >> —Owen
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > 
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory