<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/7/2015 9:42 AM, Chandler Carruth
      wrote:<br>
    </div>
    <blockquote class=" cite"
id="mid_CAGCO0KjQnJ8vkghaEa1_kg2s7SZKW8OUYvXUWzqSZ_wDnTBUdQ_mail_gmail_com"
cite="mid:CAGCO0KjQnJ8vkghaEa1-kg2s7SZKW8OUYvXUWzqSZ_wDnTBUdQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">I think it is significantly more
            friendly (and easier to debug mistakes) if the textual IR
            uses human readable names. We already have a hard time due
            to the totally opaque nature of address spaces -- there are
            magical address spaces for segment stuff in x86.
            <div><br>
            </div>
            <div>The strings are only opaque to the target-independent
              optimizer. While integers and strings are equally friendly
              to the code in the target, strings are significantly more
              friendly to humans reading the IR.</div>
            <div><br>
            </div>
            <div>The other advantage is that it makes it much harder to
              accidentally write code that relies on the particular
              values for the integers. =]</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Here's what this looks like to me:<br>
    <ol>
      <li>LLVM text format will use string symbols for memory scopes,
        and not numbers. The set of strings is target defined, but
        "singlethread" and "system" are reserved and have a well-known
        meaning.<br>
        <br>
      </li>
      <li>"The keyword informally known as system" represents the set of
        all threads that could possibly synchronize on the location
        being accessed by the current atomic instruction. These threads
        could be local, remote, executing on different agents, or
        whatever else is admissible on that particular platform. We
        still need to agree on the keyword to be used.<br>
        <br>
      </li>
      <li>The bitcode will store memory scopes as unsigned integers,
        since that is the easiest way to maintain compatibility. The
        values 0 and 1 are special. All other values are meaningful only
        within that bc file. The file will also provide a map from
        unsigned integers to string symbols which should be used to
        interpret all the non-standard integers.</li>
      <ol>
        <li>The map must not include 0 and 1, since the reader will
          internally map them to singlethread" and "system"
          respectively.</li>
        <li>If the map is empty or non-existent, then all non-zero
          values will be mapped to "system", which is the current
          behaviour.<br>
          <br>
        </li>
      </ol>
      <li>The in-memory structure for an atomic instruction will
        represent memory scope as a reference to a uniqued strings. This
        eliminates any notion of performing arithmetic on the scope
        indicator, or to write code that is sensitive to its numerical
        value.<br>
        <br>
      </li>
      <li>Behaviour is undefined if a symbolic scope used in the IR is
        not supported by the target. This is true for "singlethread" and
        "system" also, since some targets may not have those scopes.<br>
      </li>
    </ol>
    <p>Is this correct? But how does this work in the SelectionDAG?
      Also, what will this look like in TableGen files?<br>
    </p>
    <p>Sameer.<br>
      <br>
    </p>
  </body>
</html>