<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 5/30/2017 3:29 PM, Geoff Berry via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:477aa91f-9e4d-cb1b-c36e-6f1b565d47dd@codeaurora.org">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <p>Currently the AtomicExpandPass will lower the following IR:</p>
      <p>define i1 @foo(i32* %obj, i32 %old, i32 %new) {<br>
        entry:<br>
          %v0 = cmpxchg weak volatile i32* %obj, i32 %old, i32 %new <u><b>release
            acquire</b></u><br>
          %v1 = extractvalue { i32, i1 } %v0, 1<br>
          ret i1 %v1<br>
        }<br>
      </p>
      <p>to the equivalent of the following on AArch64:<br>
      </p>
      <p><tt>    <u><b>ldxr    w8, [x0]</b></u></tt><tt><br>
        </tt><tt>    cmp        w8, w1</tt><tt><br>
        </tt><tt>    b.ne    .LBB0_3</tt><tt><br>
        </tt><tt>// BB#1:                                //
          %cmpxchg.trystore</tt><tt><br>
        </tt><tt>    stlxr    w8, w2, [x0]</tt><tt><br>
        </tt><tt>    cbz    w8, .LBB0_4</tt><tt><br>
        </tt><tt>// BB#2:                                //
          %cmpxchg.failure</tt><tt><br>
        </tt><tt>    mov     w0, wzr</tt><tt><br>
        </tt><tt>    ret</tt><tt><br>
        </tt><tt>.LBB0_3:                                //
          %cmpxchg.nostore</tt><tt><br>
        </tt><tt>    clrex</tt><tt><br>
        </tt><tt>    mov     w0, wzr</tt><tt><br>
        </tt><tt>    ret</tt><tt><br>
        </tt><tt>.LBB0_4:</tt><tt><br>
        </tt><tt>    orr    w0, wzr, #0x1</tt><tt><br>
        </tt><tt>    ret</tt><br>
      </p>
      <p>GCC instead generates a ldaxr for the initial load, which seems
        more correct to me since it is honoring the requested failure
        case acquire ordering.  I'd like to get other opinions on this
        before filing a bug.<br>
      </p>
      <p>I believe the code in AtomicExpand::expandAtomicCmpXchg() is
        responsible for this discrepancy, since it only uses the failure
        case memory order for targets that use fences (i.e. when
        TLI->shouldInsertFencesForAtomic(CI) is true).<br>
      </p>
    </blockquote>
    <br>
    From LangRef: "<span style="color: rgb(0, 0, 0); font-family:
      "Lucida Grande", "Lucida Sans Unicode",
      Geneva, Verdana, sans-serif; font-size: 14px; font-style: normal;
      font-variant-ligatures: normal; font-variant-caps: normal;
      font-weight: normal; letter-spacing: normal; orphans: 2;
      text-align: left; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 2; word-spacing: 0px;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); text-decoration-style: initial; text-decoration-color:
      initial; display: inline !important; float: none;">the ordering
      constraint on failure must be no stronger than that on success".<br>
      <br>
      It's not really explained in LangRef, but per C++11, the way we
      convert the success semantic to a failure semantic for cmpxchg is
      by converted acq_rel to acquire and release to relaxed.  Acquire
      is stronger than relaxed, so your cmpxchg is illegal.  Not sure
      why the verifier isn't catching it.<br>
      <br>
      -Eli<br>
    </span>
    <pre class="moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
  </body>
</html>