<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 1/14/2015 12:51 PM, Chandler Carruth
      wrote:<br>
    </div>
    <blockquote class=" cite"
id="mid_CAGCO0Ki9UdrO2SNCSYqv56Fz6P4Gqorqxk5cADw871fZz0_mcQ_mail_gmail_com"
cite="mid:CAGCO0Ki9UdrO2SNCSYqv56Fz6P4Gqorqxk5cADw871fZz0+mcQ@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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
                moz-do-not-send="true"
                href="mailto:sameer.sahasrabuddhe@amd.com"
                target="_blank">sameer.sahasrabuddhe@amd.com</a>></span>
            wrote:<br>
            <blockquote id="Cite_4323316" class="gmail_quote cite"
              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 class=" cite" id="Cite_3387482"
                    type="cite">
                    <div dir="ltr">
                      <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>
                  </blockquote>
                </div>
              </div>
            </blockquote>
            <blockquote id="Cite_4423392" class="gmail_quote cite"
              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>
    </blockquote>
    <br>
    That makes sense. I will start with what's currently available. As
    far as a better string is concerned, scopes will be yet another
    misuse of metadata to be fixed in that separate project. <br>
    <br>
    Sameer.<br>
    <br>
  </body>
</html>