[LLVMdev] Loads moving across barriers

[Michele Scandale]

On 11/09/2013 08:45 AM, Matt Arsenault wrote:
>
> 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.

 From that discussion we reached a proposal based on metadata similar to TBAA 
that a frontend must generate describing logical address space and their 
relationship (disjointness or overlap, and constantness), and like TBAA these 
would be attached to load/store instructions. Based on these metadata it would 
be straightforward to build an alias analysis that disallow aliasing between 
logical disjoint address space and based on disjoint physical address spaces 
(this would require an hook in TargetTransformInfo).

I haven't had yet the time to implement this grouping the handling of metadata 
for alias-analysis (TBAA would be a component of this).

-Michele

> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>