
<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 9:21 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 9:13 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 style="word-wrap:break-word"><div></div></div></blockquote></div></div></blockquote><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote"><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: relative; z-index: 0; "><div style="word-wrap:break-word"><div><div>Unfortunately, we can't bail out of register allocation.</div></div></div></blockquote><div><br></div><div>But is there a cheaper algorithm we could fall over to? I don't know the first thing about regalloc, so maybe this doesn't make sense. Just trying to get a feel for whether this is solvable within the backend, or we simply must not produce such inputs.</div></div></div></blockquote><div><br></div></div>It is not impossible to fall back to RAFast which doesn't compute liveness at all, and so won't have this problem. It's a giant hack that I'd rather not do, though.<div><br></div><div>The fundamental problem is that LLVM doesn't have an IR optimizer, it has an IR canonicalizer. In this case, it's probably LICM hoisting a thousand GEPs out of a thousand-block loop, creating the quadratic problem. Normally, CodeGenPrepare would sink those GEPs again, but in this case they are used by PHIs which CGP won't touch.</div><div><br></div><div>If you sink those GEPs, I expect the problem will go away.</div><div><br></div><div>Long term, I want to replace MachineCSE and MachineLICM with a global code motion pass that can balance register and execution resource usage. That's not exactly trivial, though.</div><div><br></div><div>/jakob</div><div><br></div></body></html>