[llvm-bugs] [Bug 38846] New: LLVM lowers __atomic builtin to a function call when lowering __sync builtin to a single instruction with LOCK prefix

[via llvm-bugs]

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

            Bug ID: 38846
           Summary: LLVM lowers __atomic builtin to a function call when
                    lowering __sync builtin to a single instruction with
                    LOCK prefix
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: twoh at fb.com
                CC: llvm-bugs at lists.llvm.org

=== Test program ===

#include <cstdint>

template <typename T>
struct __attribute__((__packed__)) Foo {
    T a;
    void incAtomic() {
        __atomic_add_fetch(&a, 1, __ATOMIC_RELEASE);
    }
    void incSync() {

        __sync_add_and_fetch(&a, 1);
    }
};

int main(int argc, char** argv) {
    Foo<uint16_t> f;
    f.a = argc;
    f.incAtomic();
    f.incSync();
    return f.a;
}

=== Disassembled instructions ===
(compiled with clang++ --std=c++17 -O3 -Wall -DNDEBUG=1) 

main:
        push    rax
        mov     word ptr [rsp], di
        mov     rdi, rsp 
        mov     esi, 1
        mov     edx, 3
        call    __atomic_fetch_add_2
        lock            add     word ptr [rsp], 1 # __sync_add_and_fetch 
        movzx   eax, word ptr [rsp]
        pop     rcx
        ret

GCC's documentation for builtins
(https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/_005f_005fatomic-Builtins.html)
says that __atomic builtsins are intended to replace __sync builtins, so there
should be no semantic difference between corresponding ones. 

I believe the difference comes from the alignment checking logic
(https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CGAtomic.cpp#L768)
only included in handling __atomic builtins. However, considering that LOCK
prefix works for unaligned accesses as well, I'm not sure if that alignment
check is necessary. LOCK for unaligned memory access is expensive, but not sure
if it is more expensive than library calls.

-- 
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/20180905/e0960f09/attachment-0001.html>