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

2007-09-19 Thread Dan Gohman
Exactly, that's what I meant to say when I said when loop conditionals are runtime dependent. To ensure safety in PromoteValuesInLoop(), one needs to prove that basic-block is executed at least once. The question is how ? The most general way to do this is to convert loops like this:

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

2007-09-19 Thread Devang Patel
On Sep 19, 2007, at 9:49 AM, Dan Gohman wrote: Exactly, that's what I meant to say when I said when loop conditionals are runtime dependent. To ensure safety in PromoteValuesInLoop(), one needs to prove that basic-block is executed at least once. The question is how ? The most general

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

2007-09-19 Thread Chris Lattner
On Sep 19, 2007, at 10:49 AM, Devang Patel wrote: In the second form, code hoisted/sunk/promoted out of the loop will still be under the guard of the if. Also see tree-ssa-loop-ch.c in GCC, for example. In llvm, loop-rotation pass does this. However, what if LICM input is not processed

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

2007-09-18 Thread Dan Gohman
+ // If GEP base is NULL then the calculated address used by Store or + // Load instruction is invalid. Do not promote this value because + // it may expose load and store instruction that are covered by + // condition which may not yet folded. + if

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

2007-09-18 Thread Dan Gohman
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

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

2007-09-18 Thread 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 =

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

2007-09-18 Thread Dan Gohman
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

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

2007-09-18 Thread Devang Patel
On Sep 18, 2007, at 3:38 PM, Dan Gohman wrote: Ok, so let's tweak the testcase again: define i32 @foo(%struct.decision* %p, %struct.decision* %q) { entry: br label %blah.i blah.i:; preds = %cond_true.i, %entry %tmp3.i = icmp eq %struct.decision* null, %q