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

Dan Gohman djg at cray.com
Tue Sep 18 13:51:15 PDT 2007


> We intend to split LICM into three passes - sink, hoist and promote- 
> values. Irrespective of sinking and hoisting, promote-values should  
> not promote values that are unsafe. Avoiding hoisting GEP here will  
> solve this test case, but promote-values bug will be exposed when it  
> is supplied manually hoisted GEP.
> 
> promote-values is not in business to identify dead loops. And when  
> loop conditionals are runtime dependent it is not possible to  
> determine it at compile time at all. The fix is to check unsafe stores  
> and loads before promoting value.

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.

Dan

-- 
Dan Gohman, Cray Inc.



More information about the llvm-commits mailing list