<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
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.<br>
<br>
Sameer.<br>
<br>
<div class="moz-cite-prefix">On 1/9/2015 10:18 AM, Sameer
Sahasrabuddhe wrote:<br>
</div>
<blockquote class=" cite" id="mid_54AF5D93_2000906_amd_com"
cite="mid:54AF5D93.2000906@amd.com" type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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>
</blockquote>
<br>
<br>
</body>
</html>