[llvm-bugs] [Bug 36860] New: __atomic_{load, store} on i686 uses libcalls

[via llvm-bugs]

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

            Bug ID: 36860
           Summary: __atomic_{load,store} on i686 uses libcalls
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: pirama at google.com
                CC: llvm-bugs at lists.llvm.org

This was originall reported at the Android NDK issue tracker
(https://github.com/android-ndk/ndk/issues/521).

$ cat atomic.cpp
unsigned long long
f(unsigned long long* x)
{
  unsigned long long v;
  __atomic_load(x, &v, __ATOMIC_SEQ_CST);
  return v;  
}

void
g(unsigned long long* x, unsigned long long v)
{
  __atomic_store(x, &v, __ATOMIC_SEQ_CST);
}

$ clang++ -std=gnu++11 -O2 --target=i386-linux-android -S -o - atomic.cpp
-fno-exceptions -fno-rtti

Clang generates library calls to __atomic_{load,store}_8 while gcc implements
the operations using movq.  Marking the pointers as 8-byte aligned causes Clang
to generate cmpxchg8b.

The frontend [1] and the backend[2] delegate atomic loads and stores to
libcalls when the alighnment of the type is smaller than the size.  For i686,
where long long is aligned to 4 bytes, this causes Clang to always generate the
library call.

A possible fix is to specialize 'hasBuiltinAtomic' in TargetInfo for x86_32 and
allowing atomic operations on 4-byte-aligned pointers to 8-byte types.

[1]
https://github.com/llvm-mirror/clang/blob/f353d86deb3ea8299f37c5477dcbb9ea30558fb1/lib/CodeGen/CGAtomic.cpp#L758
[2]
https://github.com/llvm-mirror/llvm/blob/74173207d108cc27f8a02ae06ad90cad42b69b91/lib/CodeGen/AtomicExpandPass.cpp#L188

-- 
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/20180321/3ed1d0a5/attachment.html>