[LLVMbugs] [Bug 16341] New: [Optimisation] Systems with load-linked/store-conditional could `merge' some atomic operations

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16341

            Bug ID: 16341
           Summary: [Optimisation] Systems with
                    load-linked/store-conditional could `merge' some
                    atomic operations
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: ed at 80386.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Consider the following piece of code:

---------------------------------------------------------------------
#include <assert.h>
#include <stdatomic.h>
#include <stdbool.h>

_Atomic(int) cur = ATOMIC_VAR_INIT(0);
static const int max = 100;

bool
allocate(void)
{
        int old;

        old = atomic_load_explicit(&cur, memory_order_relaxed);
        do {
                if (old >= max)
                        return false;
        } while (!atomic_compare_exchange_weak_explicit(&cur, &old, old + 1,
            memory_order_relaxed, memory_order_relaxed));
        return true;
}

void
deallocate(void)
{
        int old;

        old = atomic_fetch_sub_explicit(&cur, 1, memory_order_relaxed);
        assert(old > 0);
}
---------------------------------------------------------------------

In other words, it implements a simple counter to constrain the number of
users. Examples: maximum number of file descriptors/sockets/etc in an OS
kernel.

In theory, allocate() could be translated to the following sequence of
instructions:

...
ldrex r0, [...]
cmp r0, #100
bge ...
add r1, r0, #1
strex r0, r1, [...]
...

Instead, I see the following:

00000000 <acquire>:
   // Do a load + add
   0:   e59fc03c        ldr     ip, [pc, #60]   ; 44 <acquire+0x44>
   4:   e59c2000        ldr     r2, [ip]
   8:   e3a00000        mov     r0, #0  ; 0x0
   c:   e3520063        cmp     r2, #99 ; 0x63
  10:   c12fff1e        bxgt    lr
  14:   e2820001        add     r0, r2, #1      ; 0x1

  // Do a compare + exchange
  18:   e19c3f9f        ldrex   r3, [ip]
  1c:   e1530002        cmp     r3, r2
  20:   1a000002        bne     30 <acquire+0x30>
  24:   e18c1f90        strex   r1, r0, [ip]
  28:   e3510000        cmp     r1, #0  ; 0x0
  2c:   1afffff9        bne     18 <acquire+0x18>

  // Handle compare + exchange result
  30:   e1530002        cmp     r3, r2
  34:   e3a00001        mov     r0, #1  ; 0x1
  38:   e1a02003        mov     r2, r3
  3c:   1afffff1        bne     8 <acquire+0x8>
  40:   e12fff1e        bx      lr
  44:   00000000        .word   0x00000000

LLVM/Clang version used:

FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
Target: armv6-unknown-freebsd10.0
Thread model: posix

-- 
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/20130616/2a662c7d/attachment.html>