https://bugs.llvm.org/show_bug.cgi?id=38450
Chandler Carruth <chandl...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #1 from Chandler Carruth <chandl...@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
