[LLVMdev] Loads moving across barriers

[Matt Arsenault]

On Nov 8, 2013, at 1:53 PM, Owen Anderson <resistor at mac.com> wrote:

> 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.
> 
> —Owen

I don’t think think outright disallowing this transform is the right solution. This would be valid for OpenCL private or constant address spaces, it’s just global or local where this would be a problem. This comes back to the questions about how to handle address space alias information which there was a long thread about a few months ago. There was debate over address spaces as a language vs. a target concept, and I don’t remember right now what the consensuses were there. The more I think about it, the more an OpenCL specific alias analysis makes sense, which could then use a men_fence intrinsic per address space.