> 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. _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits