<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
code
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">The LLVM source interprets it as <a href="https://github.com/llvm/llvm-project/blob/a5d375e0cbc4abf6e318270a1bc9c1c0961ae565/llvm/include/llvm/Support/AtomicOrdering.h#L89">
https://github.com/llvm/llvm-project/blob/a5d375e0cbc4abf6e318270a1bc9c1c0961ae565/llvm/include/llvm/Support/AtomicOrdering.h#L89</a> .<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We should probably drop the requirement; the C++ standard dropped the corresponding requirement for the library call. See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0418r2.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0418r2.html</a> .<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Eli<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org>
<b>On Behalf Of </b>Oliver Giersch via llvm-dev<br>
<b>Sent:</b> Saturday, April 4, 2020 3:59 AM<br>
<b>To:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> [EXT] [llvm-dev] Permitted success/failure orderings for atomic compare_exchange<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">A question has come up on how to interpret the wording of LLVM's documentation regarding the possible memory ordering for success and failure of atomic compare_exchange operations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">From the LLVM reference:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">"The success and failure <a href="https://llvm.org/docs/LangRef.html#ordering">
ordering</a> arguments specify how this <code><span style="font-size:10.0pt">cmpxchg</span></code> synchronizes with other atomic operations. Both ordering parameters must be at least
<code><span style="font-size:10.0pt">monotonic</span></code> , the ordering constraint on failure must be no stronger than that on success, and the failure ordering cannot be either
<code><span style="font-size:10.0pt">release</span></code> or <code><span style="font-size:10.0pt">acq_rel</span></code> ."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">The way this operation is implemented in the standard library of the Rust programming language, the combination of release (success) and acquire (failure) is not permitted and will fail at runtime, the prevailing
opinion being, that a failing CAS with release/acquire ordering is actually relaxed on the store part and hence acquire ordering for the failure case would be stronger.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">However, I don't believe that this a correct reading of the specification and that neither acquire nor release should be considered stronger or weaker than the other and that hence that combination should be permitted.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I had hoped to get get some clarification on this issue here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>