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. > > —OwenI 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.
So, I don't have a horse in the OpenCL race, and I'd like to mostly keep it that way, but I want to point out that some of these things have much broader implications. On Fri, Nov 8, 2013 at 11:45 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:> 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.Unless I've misunderstood (which is a possibility, I've not invested proper time thinking about this, which I'll do if you indicate I'm missing something), this would be tantamount to tying certain address to specific rules regarding potential data races in the memory model. I'm not very comfortable with that. Perhaps you're instead trying to say that with certain address spaces "noalias" (and by inference, "restrict" at the language level) has a different semantic model than other address spaces? While it's less worrisome than the first interpretation, I still don't really like it.> 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.I think if OpenCL has special aliasing properties for specific address spaces it would make much more sense (IMO) to either have a specialized alias analysis that implements this, or to work out a proper metadata-based system for expressing these constraints from the frontend. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131109/c40bc1b3/attachment.html>
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 >
On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at google.com> wrote:> > Perhaps you're instead trying to say that with certain address spaces "noalias" (and by inference, "restrict" at the language level) has a different semantic model than other address spaces? While it's less worrisome than the first interpretation, I still don't really like it. >This sounds right. With the constant address space, anything you do is OK since it’s constant. Private address space is supposed to be totally inaccessible from other workitems, so parallel modifications aren’t a concern. The others require explicit synchronization which noalias would need to be aware of.