<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 10:42 PM, Sameer Sahasrabuddhe <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"><div class="adM"><div class=""><div>On 1/14/2015 12:03 PM, Chandler Carruth
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Tue, Jan 13, 2015 at 10:27 PM,
            Sameer Sahasrabuddhe <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">Ping! We need to close on whether
              everyone is convinced that symbolic memory scopes have a
              significant advantage over opaque numbers. Either of them
              will be examined by optimizations using a
              target-implemented API. I personally don't think that
              readability in the LLVM text format is worth the effort,
              especially given that address spaces work well enough with
              opaque numbers.</blockquote>
            <div><br>
            </div>
            <div>I am much more comfortable with symbolic memory scopes.
              The reason I feel this way is actually because there *is*
              a particular ordering of them that the target will
              mandate. Having an ordering but having it *not* be the
              order of the numbers used seems too actively confusing to
              me. </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div></div>
    All that is true about address spaces too. On some platforms,
    address spaces could have a subset relationship, but it would be
    wrong to infer that from the numerical value. Isn't it enough to say
    that the number is opaque and should not be interpreted via any
    comparison?<br></blockquote><div><br></div><div>My understanding is that there is much less of this. I also wasn't heavily involved in the address space design, and that design also has to cope with more entrenched legacy in other systems and interfaces. Not sure how much it makes sense to base the design on that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    <br>
    I do see your ponit, though. But now the task got much bigger and
    will have to reexamine the time required. I suppose it starts with
    bitcode reader that can interpret existing bitcode files and
    translate the scopes to symbols instead.</blockquote></div><br>I"m sympathetic here. We really should have an easy way of encoding this kind of thing. You might be able to use "metadata" in the same way that @llvm.read_register does, where it is not really metadata in the traditional sense and can't be "stripped" or "discarded" in any way. As I wrote in my email, I think this should be replaced by something which more formally models this idea, but I don't think this work should be held hostage waiting for that better system to arrive. However, I also don't think this better system of synthetic constant strings is very hard to build if your interested, and it would serve a lot of use cases outside of synchronization scopes.</div></div>