[llvm-bugs] [Bug 33332] New: atomic cmpxchg release acquire doesn't reject or honor failure memory ordering

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=33332

            Bug ID: 33332
           Summary: atomic cmpxchg release acquire doesn't reject or honor
                    failure memory ordering
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: gberry at codeaurora.org
                CC: llvm-bugs at lists.llvm.org

Currently the AtomicExpandPass will lower the following IR:

define i1 @foo(i32* %obj, i32 %old, i32 %new) {
entry:
  %v0 = cmpxchg weak volatile i32* %obj, i32 %old, i32 %new release acquire
  %v1 = extractvalue { i32, i1 } %v0, 1
  ret i1 %v1
}

to the equivalent of the following on AArch64:

    ldxr    w8, [x0]
    cmp        w8, w1
    b.ne    .LBB0_3
// BB#1:                                // %cmpxchg.trystore
    stlxr    w8, w2, [x0]
    cbz    w8, .LBB0_4
// BB#2:                                // %cmpxchg.failure
    mov     w0, wzr
    ret
.LBB0_3:                                // %cmpxchg.nostore
    clrex
    mov     w0, wzr
    ret
.LBB0_4:
    orr    w0, wzr, #0x1
    ret

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.

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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170606/abd42e3c/attachment.html>