[llvm-bugs] [Bug 38450] cmp+store is not optimized to an unconditional store

[via llvm-bugs]

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

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> ---
(In reply to Gonzalo BG from comment #0)
> See https://godbolt.org/g/5W5q2K , the following LLVM-IR:
> 
> define void @foo(i32* noalias nocapture dereferenceable(4) %x) {
> start:
>   %0 = load i32, i32* %x, align 4
>   %1 = icmp eq i32 %0, 0
>   br i1 %1, label %bb2, label %bb1
> 
> bb1:
>   store i32 0, i32* %x, align 4
>   br label %bb2
> 
> bb2:
>   ret void
> }
> 
> does not optimize to anything better with opt -O3. Using llc, it generates
> the following x86_64 assembly code (https://godbolt.org/g/RX81Sn): 
> 
>     cmpl    $0, (%rdi)
>     je      .LBB0_2
>     movl    $0, (%rdi)
> .LBB0_2:  
>     retq
> 
> I would expect this to just generate "movl $0, (%rdi); retq".

LLVM's memory model precludes this -- it would introduce a store along a code
path that didn't originally have one.

The routine could be called with other threads concurrently reading the data
which is fine as long as the data is zero and thus no thread writes to the
data.

The analogous constraint also exists in C++'s memory model FWIW.

-- 
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/20180805/78cb9dca/attachment.html>