<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 12/11/2014 4:28 PM, Sahasrabuddhe,
Sameer wrote:<br>
</div>
<blockquote class=" cite" id="mid_548978D9_3070707_amd_com"
cite="mid:548978D9.3070707@amd.com" type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br>
Attached is a sequence of patches that changes the IR to support
more than two synchronization scopes. This is still a work in
progress, and these patches are only meant to start a more
detailed discussion on the way forward.<br>
<br>
</blockquote>
<br>
Ping! <br>
<br>
Found a simple way to preserve forward compatibility. See below.<br>
<br>
<blockquote class=" cite" id="mid_548978D9_3070707_amd_com"
cite="mid:548978D9.3070707@amd.com" type="cite"> One big issue is
the absence of any backend that actually makes use of intermediate
synchronization scopes. This work is meant to be just one part of
the ground work required for landing the much-anticipated HSAIL
backend. Also, more work might be needed for emitting atomic
instructions via Clang.<br>
<br>
The proposed syntax for synchronization scope is as follows:<br>
<ol>
<li>Synchronization scopes are of arbitrary width, but
implemented as unsigned in the bitcode, just like address
spaces.</li>
<li>Cross-thread is default, but now encoded as 0.<br>
</li>
<li>Keyword 'singlethread' is unchanged, but now encoded as the
largest integer (which happens to be ~0U in bitcode).<br>
</li>
<li>New syntax "synchscope(n)" for other scopes.</li>
<li>There is no keyword for cross-thread, but it can be
specified as "synchscope(0)".</li>
</ol>
<p>This change breaks forward compatibility for the bitcode, since
the meaning of the zero/one values are now changed.<br>
</p>
<p><tt> enum SynchronizationScope {</tt><tt><br>
</tt><tt>- SingleThread = 0,</tt><tt><br>
</tt><tt>- CrossThread = 1</tt><tt><br>
</tt><tt>+ CrossThread = 0,</tt><tt><br>
</tt><tt>+ SingleThread = ~0U</tt><tt><br>
</tt><tt> };</tt><br>
</p>
<p>The change passes almost all lit tests including one new test
(see patch 0005). The failing tests are specifically checking
for forward compatibility:<br>
<br>
Failing Tests (3):<br>
LLVM :: Bitcode/cmpxchg-upgrade.ll<br>
LLVM :: Bitcode/memInstructions.3.2.ll<br>
LLVM :: Bitcode/weak-cmpxchg-upgrade.ll<br>
<br>
This breakage remains even if we reverse the order of
synchronization scopes. One simple way to preserve compatibility
is to retain 0 and 1 with their current meanings, and specify
that intermediate scopes are represented in an ordered way with
numbers greater than one. But this is pretty ugly to work with.
Would appreciate inputs on how to fix this!<br>
</p>
</blockquote>
<br>
The issue here is purely in the bitcode, and we need an encoding
that can represent new intermediate scopes while preserving the two
known values of zero and one. Note that the earlier zero is now ~0U
in the in-memory representation, and the earlier 1 is now zero. This
mapping can be easily accomplished with a simple increment/decrement
by one, ignoring overflow. So the bitreader now subtracts a one when
decoding the synch scope, and bitwriter adds a one when encoding the
synch scope. The attached change number 0006 is meant to replace
changes 0003 and 0005 in the previous list, since the assembly and
the bitcode need to be updated simultaneously for this to work.<br>
<br>
The new change passes all tests, including the ones checking for
forward compatibility.<br>
<br>
Sameer.<br>
<br>
</body>
</html>