[llvm-commits] [llvm] r159746 - /llvm/trunk/lib/CodeGen/LiveInterval.cpp

Jakob Stoklund Olesen stoklund at 2pi.dk
Thu Jul 5 10:32:42 PDT 2012


On Jul 5, 2012, at 10:02 AM, Chandler Carruth <chandlerc at gmail.com> wrote:

> While this is interesting, it isn't what I'm looking at. I don't have any test cases that currently point a finger at extendInBlock (but that may change, see below).
> 
> I'm working on a patch to fix the super-linear performance of MergeValueInAsValue (and MergeRangeInAsValue). I've two or three ideas, and should have a patch mailed out today.

That would be great.

Those functions are called from the spiller to update the stack intervals. You can pretty much assume that the destination only has a single value number. You should also look out for noop calls, i.e. calls that don't change the destination interval.

A long term plan of mine is to implement LiveInterval with an IntervalMap backing store. The B+-tree gets rid of the quadratic behavior, but it is probably slower in average.

> I spotted the merge-able remove calls by inspection, and was inspecting it because the remove is what makes the above super-linear so it showed up blazing hot in the profile.
> 
> I never really expected this patch to make a big difference, it only seemed worth it because the code actually became simpler in the process.

On a more general note, it is my experience that performance trouble in LiveIntervals usually come from pathologically bad block layout. The data structures are sub-linear for sane code, but if you insert a million blocks at the end of the function (hi, asan), the intervals blow up.

I don't want to change the block layout during register allocation, so my plan for dealing with this is to base SlotIndex numbering on MBB numbers instead of MBB layout. The basic blocks could be renumbered topologically with a bias towards the layout.

/jakob




More information about the llvm-commits mailing list