<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 10, 2012, at 8:50 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div class="im">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.</div></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></div></blockquote><div><br></div><div>Unfortunately, we can't bail out of register allocation.</div><div><br></div><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote"><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.</div></div></div></blockquote><div><br></div><div>Good idea.</div><div><br></div></div></body></html>