[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