[LLVMdev] [RFC][PATCH][OPENCL] synchronization scopes redux (original) (raw)

Chandler Carruth chandlerc at google.com
Tue Jan 6 19:29:23 PST 2015

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:

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>

More information about the llvm-dev mailing list