[llvm-dev] Memory scope proposal

[Mehdi Amini via llvm-dev]

> On Aug 21, 2016, at 8:51 PM, Sameer Sahasrabuddhe <sameer at sbuddhe.net> wrote:
> 
> On Sun, Aug 21, 2016 at 11:49 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> On Aug 21, 2016, at 11:14 AM, Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>> 
>> Given my current time commitments, having me on the critical path for any proposal is not a good idea.  I'm willing to step aside here as long as the proposal is well reviewed by someone who's familiar with the memory model.  Hal, Sanjoy, JF, Chandler, and Danny would all be reasonable alternates. 
> 
> OK, good to know. I put you on the path because you wrote:
> 
> "I am opposed to extending the instructions without a strong motivating case.  I don't care anywhere near as much about metadata based schemes, but extending the instruction semantics imposes a much larger burden on the rest of the community.  That burden has to be well justified and supported."
> 
> It is not clear to me right now if the "use case" makes it "well justified" or not (an alternative being using intrinsic for OpenCL as Justin Lebar mentioned). I don’t feel I can answer this, so adding CC Chandler and Sanjoy to begin with.
> 
> One yardstick to determine if this is "well justified" is to ask if any LLVM backend has an undefined behaviour similar to OpenCL if the scope metadata is dropped. For every LLVM target X which can be potentially targetted from OpenCL, if the metadata is dropped (in one module but not another), does the memory model for X still produce behaviour that is compatible with the behaviour intended by the original program? If that question cannot be answered satisfactorily for all cases, then metadata is not a reliable way to move forward.
> 
> To put it differently, when viewed as an "OpenCL implementation", can every LLVM backend guarantee that when OpenCL scopes are lowered to metadata, the synchronisation specified in the original program is preserved?

This does not address why you can’t use intrinsics (like the CUDA implementation does apparently).

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160821/7fbfa16e/attachment.html>