<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 12:31 AM, Sahasrabuddhe, Sameer <span dir="ltr"><<a href="mailto:sameer.sahasrabuddhe@amd.com" target="_blank">sameer.sahasrabuddhe@amd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">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...</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">Dunno, thoughts?</div>
      </div>
    </blockquote>
    <br></span>
    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?</blockquote><div><br></div><div>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.</div><div><br></div><div>I think the "strings" can be made relatively clean.</div><div><br></div><div>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. ;]</div><div><br></div><div>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:</div><div><br></div><div>- It ensures we have no bitcode stability problems.</div><div>- 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.</div><div>- 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
    <br>
    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.</blockquote></div><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, my current leaning is to try to figure out a reasonably clean way to use strings, similar to the target-specific attributes.</div></div>