<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 8:03 PM, 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"><div bgcolor="#FFFFFF" text="#000000">Here's what this looks like to me:<br>
    <ol>
      <li>LLVM text format will use string symbols for memory <span class="il">scopes</span>,
        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 <span class="il">synchronize</span> 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 <span class="il">scopes</span> 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 <span class="il">scope</span> as a reference to a uniqued strings. This
        eliminates any notion of performing arithmetic on the <span class="il">scope</span>
        indicator, or to write code that is sensitive to its numerical
        value.<br>
        <br>
      </li>
      <li>Behaviour is undefined if a symbolic <span class="il">scope</span> 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 <span class="il">scopes</span>.<br>
      </li>
    </ol>
    <p>Is this correct?</p></div></blockquote><div>Generally, yes.</div><div><br></div><div>Regarding the specific way of using strings, see the email I just sent about metadata being used poorly, this is a place where we might use metadata to encode the string, or we might do something more direct as you propose. I think it would be good to do something like what I propose in that thread to have nicely uniqued opaque string entities in the IR, and then use them here for marking scopes. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><p> But how does this work in the SelectionDAG?
      Also, what will this look like in TableGen files?</p></div></blockquote></div>Not sure what you mean here? I haven't looked at implementing it, but from the DAG down you should get to collapse this rapidly toward target-specific nodes / structures / representations?</div></div>