[llvm-commits] [llvm] r122791 - /llvm/trunk/lib/Transforms/Scalar/LoopInstSimplify.cpp
clattner at apple.com
Tue Jan 4 00:06:14 CST 2011
On Jan 3, 2011, at 6:54 PM, Cameron Zwarich wrote:
> On Jan 3, 2011, at 5:58 PM, Chris Lattner wrote:
>> On Jan 3, 2011, at 4:12 PM, Cameron Zwarich wrote:
>>> Author: zwarich
>>> Date: Mon Jan 3 18:12:46 2011
>>> New Revision: 122791
>>> URL: http://llvm.org/viewvc/llvm-project?rev=122791&view=rev
>>> Address most of Duncan's review comments. Also, make LoopInstSimplify a simple
>>> FunctionPass. It probably doesn't have a reason to be a LoopPass, as it will
>>> probably drop the simple fixed point and either use RPO iteration or Duncan's
>>> approach in instsimplify of only revisiting instructions that have changed.
>> Hi Cameron,
>> If it's not a loop pass, it won't be pipelined along with the other loop passes, right?
> That's correct, but ScalarEvolution runs right after instcombine here and also breaks the loop pass pipelining, so we'll need to solve that problem there too. As long as ScalarEvolution breaks loop pass pipelining, there isn't really much gained from running LoopInstSimplify as a loop pass.
> If both LoopInstSimplify and ScalarEvolution preserve LoopSimplify and LCSSA (even as function passes rather than loop passes), shouldn't the loop pass manager skip recomputing them? Or is there something I am missing?
ScalarEvolution is an analysis, not a transformation, so it should trivially preserve LCSSA. The right long term fix (IMO) is for all the loop passes to preserve ScalarEvolution. This will cause the passmgr to run ScalarEvolution before all of the loop passes, then the loop passes can all be pipelined naturally.
More information about the llvm-commits