[LLVMbugs] [Bug 21084] Right-hand side of logical expression gets speculated, causing jump on uninitialized value

[bugzilla-daemon at llvm.org]

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #1 from Hans Wennborg <hans at chromium.org> ---
Bisection points to r216814: InstCombine: Try harder to combine icmp
instructions

But it's SimplifyCFG that speculates the load and ands all the conditions
together:

*** IR Dump After Module Verifier ***
; Function Attrs: uwtable
define void @_Z4testv() #0 {
entry:
  %local = alloca i32, align 4
  %call = call zeroext i1 @_Z7ReadIntPi(i32* %local)
  br i1 %call, label %land.lhs.true, label %if.end

land.lhs.true:                                    ; preds = %entry
  %0 = load i32* %local, align 4
  %cmp = icmp slt i32 %0, 8
  br i1 %cmp, label %land.lhs.true1, label %if.end

land.lhs.true1:                                   ; preds = %land.lhs.true
  %1 = load i32* %local, align 4
  %cmp2 = icmp sge i32 %1, 0
  br i1 %cmp2, label %if.then, label %if.end

if.then:                                          ; preds = %land.lhs.true1
  call void @_Z1fv()
  br label %if.end

if.end:                                           ; preds = %if.then,
%land.lhs.true1, %land.lhs.true, %entry
  ret void
}
*** IR Dump After Simplify the CFG ***
; Function Attrs: uwtable
define void @_Z4testv() #0 {
entry:
  %local = alloca i32, align 4
  %call = call zeroext i1 @_Z7ReadIntPi(i32* %local)
  %0 = load i32* %local, align 4
  %cmp = icmp slt i32 %0, 8
  %or.cond = and i1 %call, %cmp
  %1 = load i32* %local, align 4
  %cmp2 = icmp sge i32 %1, 0
  %or.cond1 = and i1 %or.cond, %cmp2
  br i1 %or.cond1, label %if.then, label %if.end

if.then:                                          ; preds = %entry
  call void @_Z1fv()
  br label %if.end

if.end:                                           ; preds = %if.then, %entry
  ret void
}


We're speculating the load from the stack and doing arithmetic with an undef
value, which is fine. The surprise comes when this turns into jumping on an
undef value after lowering to X86.

After discussing this, the current view is that the generated code is correct,
it will not be a problem for MSan as it works on the IR level, and should be
added to the list of optimizations that Valgrind has trouble with.

-- 
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/20140927/f8fa6a55/attachment.html>