<div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 10, 2012 at 8:33 AM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank" class="cremed">stoklund@2pi.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Jul 9, 2012, at 11:34 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="cremed">chandlerc@gmail.com</a>> wrote:<br>
<br>
> This will in theory (hehe, see below) make many parts of LLVM work faster where the algorithms are tuned for "normal" CFG patterns in code. Previously ASan would create massive live ranges by inserting basic blocks onto the end of the function.<br>

><br>
> Currently this would cause some minor regressions in performance, but that will be fixed by a subsequent patch that attaches branch weight metadata to the appropriate places in the generated code. These will then allow the block placement pass to re-order the basic blocks into the optimal layout at the very end of codegen.<br>

><br>
> Sadly, this bright and shiny future is not where we are. Applying this patch and re-running the regression test Kostya added to PR13225 (which is actually a repro for PR12652) the codegen time slows down **massively**. The profile also looks quite different:<br>

<br>
</div>Strange. I suppose that if you are now inserting a million abort() calls in line, the live ranges still get chopped into tiny pieces.<br>
<br>
LiveVariables is mostly independent of block layout, and its algorithm is inherently quadratic for your test case. That explains the samples you are seeing in LiveVariables and SparseBitVector.<br>
<br>
I would like to see a backtrace on those std::vector<MachineBasicBlock*>:insert samples, but it's probably  LiveVariables::MarkVirtRegAliveInBlock() again. (It's using insert() to append elements to a vector, not to insert in the middle).<br>

<br>
FWIW, I am planning to rip out LiveVariables and compute LiveIntervals directly from the machine code using LiveRangeCalc. This is already done for regunit liveness. This may help the constant factor, but it is still the same algorithm.</blockquote>
<div><br></div><div>Hrm... I wonder if it's worth having an adaptive algorithm so that we bail out quickly when the structure of the function is going to quickly go quadratic with the algorithm? Even if it costs some optimization, that would seem better than grinding codegen to a halt.</div>
<div><br></div><div><br></div><div>That said, about 40% of what the profile is showing (which  may or may not be that accurate sadly...) isn't out of LiveVariables, its TwoAddressInstructionPass (and its helper findLocalKills). I'm going to work on that one and see if I can get that to go away -- it doesn't look inherently slow at first glance.<br>
</div><div><br></div><div>-Chandler</div></div></div>