[llvm-commits] [llvm] r158790 - in /llvm/trunk: include/llvm/Analysis/LoopInfo.h include/llvm/Analysis/LoopInfoImpl.h lib/Analysis/LoopInfo.cpp lib/CodeGen/MachineLoopInfo.cpp

Andrew Trick atrick at apple.com
Wed Jun 20 15:42:37 PDT 2012


On Jun 20, 2012, at 6:19 AM, "Rotem, Nadav" <nadav.rotem at intel.com> wrote:
> I also noticed that adding basic blocks to all loop-lest levels can result in quadratic runtime.   :(

If the quadratic nature of LoopInfo is a problem, we need to redesign the way it stores its result which would significantly affect (probably improve) the API. I welcome this, but it's outside the scope of my checkin.

My first implementation (which I was working on until yesterday), inserted blocks in place in RPO order and bulk copied blocks from subloops into parent loops. I got it working but it was excessively complicated and I'm very happy I ditched it.

We could potentially microoptimize block insertion various ways. We could avoid std::reverse either by changing the LoopInfo result data structure from vector to deque, or by keeping an extra map during analysis. Measuring the impact would be hard. I already learned my lesson about microoptimizing this code, but others are welcome to have at it. If I have more time to work on this my priority will be:

- Make the Blocks lists exclusive (not quadtratic)

- Provide a way to check that the blocks are in RPO order, put them back in RPO order if required

Just having them mostly in RPO order is already a benefit though. For example, iterative dataflow converges faster but doesn't repend on the property.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120620/1eb02f7c/attachment.html>


More information about the llvm-commits mailing list