[llvm-dev] Memory scope proposal

[Sameer Sahasrabuddhe via llvm-dev]

On Sun, Aug 21, 2016 at 11:49 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

> On Aug 21, 2016, at 11:14 AM, Philip Reames <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?

Sameer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160822/ef4edefa/attachment.html>