[LLVMdev] [RFC][PATCH][OPENCL] synchronization scopes redux

[Chandler Carruth]

On Tue, Jan 6, 2015 at 12:31 AM, Sahasrabuddhe, Sameer <
sameer.sahasrabuddhe at amd.com> wrote:

> I'm starting to think we might actually need to let the target define
> acceptable strings for memory scopes and a strict weak ordering over
> them.... That's really complex and heavy weight, but I'm not really
> confident that we're safe committing to something more limited. The good
> side is that we can add the SWO-stuff lazily as needed...
>
>  Dunno, thoughts?
>
>
> Just the thought of using strings in the IR smells like over-design to me.
> Going back to the original point, are target-independent optimizations on
> scoped atomic operations really so attractive?


Essentially, I think target-independent optimizations are still attractive,
but we might want to just force them to go through an actual
target-implemented API to interpret the scopes rather than making the
interpretation work from first principles. I just worry that the targets
are going to be too different and we may fail to accurately predict future
targets' needs.

I think the "strings" can be made relatively clean.

What I'm imagining is something very much like the target-specific
attributes which are just strings and left to the target to interpret, but
are cleanly factored so that the strings are wrapped up in a nice opaque
attribute that is used as the sigil everywhere in the IR. We could do this
with metadata, and technically this fits the model of metadata if we make
the interpretation of the absence of metadata be "system". However, I'm
quite hesitant to rely on metadata here as it hasn't always ended up
working so well for us. ;]

I'd be interested in your thoughts and others' thoughts on how me might
encode an opaque string-based scope effectively. If we can find a
reasonably clean way of doing it, it seems like the best approach at this
point:

- It ensures we have no bitcode stability problems.
- It makes it easy to define a small number of IR-specified values like
system/crossthread/allthreads/whatever and singlethread, and doing so isn't
ever awkward due to any kind of baked-in ordering.
- In practice in the real world, every target is probably going to just
take this and map it to an enum that clearly spells out the rank for their
target, so I suspect it won't actually increase the complexity of things
much.


>
>
> But while the topic is wide open, here's another possibly whacky approach:
> we let the scopes be integers, and add a "scope layout" string similar to
> data-layout. The string encodes the ordering of the integers. If it is
> empty, then simple numerical comparisons are sufficient. Else the string
> spells out the exact ordering to be used. Any known current target will be
> happy with the first option. If some target inserts an intermediate scope
> in the future, then that version switches from empty to a fully specified
> string. The best part is that we don't even need to do this right now, and
> only come up with a "scope layout" spec when we really hit the problem for
> some future target.


This isn't a bad approach, but it seems even more complex. I think I'd
rather go with the fairly boring one where the IR just encodes enough data
for the target to answer queries about the relationship between scopes.

So, my current leaning is to try to figure out a reasonably clean way to
use strings, similar to the target-specific attributes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150106/ac8d4368/attachment.html>