<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/9/2015 4:14 AM, Chandler Carruth
wrote:<br>
</div>
<blockquote class=" cite"
id="mid_CAGCO0Ki__rtnuDMOA3V54grTBYukVyvhSSUF_9hOk_RMQn39eg_mail_gmail_com"
cite="mid:CAGCO0Ki==rtnuDMOA3V54grTBYukVyvhSSUF_9hOk_RMQn39eg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">On Wed, Jan 7, 2015 at 8:03 PM,
Sahasrabuddhe, Sameer <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>
<div class="gmail_quote">
<blockquote id="Cite_4481710" class="gmail_quote cite"
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. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
So I see the following large chunks of work that are difficult to
isolate:<br>
<ol>
<li>Modifying the bitcode and assembly readers and writers.<br>
</li>
<li>Updating Clang (simultaneously?) to generate the new kind of
IR with symbol/number mappings.<br>
</li>
<li>Updating language bindings to deal with the new IR.</li>
</ol>
<p>As far as I can see, the following can be decoupled from the
above, but they are closely tied to each other:<br>
</p>
<ol start="4">
<li>Implementing uniqued opaque strings in the most desirable way,
and using it for the in-memory format.</li>
<li>Creating an interface to convert the opaque symbols into
suitable target-specific DAG nodes.<br>
</li>
</ol>
All this work, just to ensure readability in the LLVM text format. I
am not entirely convinced that it is worth it, when opaque integers
can get the job done just like address spaces ... are you?<br>
<br>
<blockquote class=" cite"
id="mid_CAGCO0Ki__rtnuDMOA3V54grTBYukVyvhSSUF_9hOk_RMQn39eg_mail_gmail_com"
cite="mid:CAGCO0Ki==rtnuDMOA3V54grTBYukVyvhSSUF_9hOk_RMQn39eg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote id="Cite_3361685" class="gmail_quote cite"
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>
</blockquote>
<br>
Sorry, that was just me being lazy and not reading up on the
SelectionDAG. I expect that we will translate the the symbols into
integer TargetConstant SDNodes ... do you see the need to be more
flexible than that?<br>
<br>
Sameer.<br>
</body>
</html>