[llvm-commits] [llvm] r42075 - in /llvm/trunk: lib/Transforms/Scalar/LICM.cpp test/Transforms/LICM/2007-09-17-PrompteValue.ll

[Devang Patel]

On Sep 18, 2007, at 1:51 PM, Dan Gohman wrote:

> I don't quite follow. For example of what I'm saying, take this
> testcase, which is only slightly different than the earlier one:
>
>
> define i32 @foo(%struct.decision* %p) {
> entry:
>       br label %blah.i
>
> blah.i:                ; preds = %cond_true.i, %entry
>       %tmp3.i = icmp eq %struct.decision* null, null          ; <i1>  
> [#uses=1]
>       br i1 %tmp3.i, label %clear_modes.exit, label %cond_true.i
>
> cond_true.i:           ; preds = %blah.i
>       %tmp1.i = getelementptr %struct.decision* %p, i32 0, i32  
> 0            ; <i8*> [#uses=1]
>       store i8 0, i8* %tmp1.i
>       br label %blah.i
>
> clear_modes.exit:              ; preds = %blah.i
>       call void @exit( i32 0 )
>       unreachable
> }
>
> declare void @exit(i32)
>
>
> Even with the latest changes, LICM puts a load of %tmp1.i in the
> entry block, which isn't safe.

It is not safe, because cond_true.i is a dead basic-block. The  
question is -- Is it LICM's responsibility to evaluate conditions and  
identify dead code or let other passes handle this earlier?. For  
example here, instruction combiner will fold comparison and cfg  
simplifier will take care of cond_true.i before LICM is executed in  
standard pass sequence.
-
Devang