Hi Jonas,<div><br></div><div>As Jakob mentioned, PBQP is designed to provide support constraints that aren't supported in the current model, without requiring any modifications to the PBQP allocator itself. Constraints are expressed to the PBQP allocator via matrices, as described in <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-September/034781.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-September/034781.html</a> .</div>
<div><br></div><div>If you decide to try the PBQP route and need pointers to further material, or help with the API, please just let me know.</div><div><br></div><div>- Lang.</div><div><br></div><div><br></div><div><div class="gmail_quote">
On Fri, Jan 20, 2012 at 9:34 AM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk">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 style="word-wrap:break-word"><br><div><div class="im"><div>On Jan 20, 2012, at 6:40 AM, Jonas Paulsson wrote:</div><br><blockquote type="cite">



<div style="WORD-WRAP:break-word">
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff"> > </font></span>What exactly are you proposing? Why can't 
you do what the PowerPC and Hexagon targets do?<font face="Arial" color="#0000ff"></font></div><div><font face="Arial" color="#0000ff"></font></div>
<div><font face="Arial" color="#0000ff"></font> </div>
<div><span><font face="Arial" color="#0000ff">Yes, I 
can move a CR to a GPR and save it to the stack, but due to a very irregular 
register file this is about 10 times more expensive than saving/restoring an 
ordinary register. These registers should basically never</font></span></div>
<div><span><font face="Arial" color="#0000ff">have 
to be spilled, at least not on -O3.</font></span></div></div></blockquote><div><br></div></div><div>And the register allocator is trying very hard not to do that, but sometimes it just isn't possible.</div><div><br></div>
<div>You have the choice between aborting compilation or inserting expensive spill code when that happens.</div><div class="im"><div><br></div><blockquote type="cite"><div style="WORD-WRAP:break-word"><div><div><span><font face="Arial" color="#0000ff">Basically, I would like to make sure that the GPR_CR reg is not spilled 
before another GPR-only reg is spilled, as it would be idiotic. As the 
super-register is wider than the GPR I do not see why this happened, but at 
-O0</font></span></div>
<div><font face="Arial"><font><font color="#0000ff"><span>this happened for some reason or other. 
</span></font></font></font></div></div></div></blockquote><div><br></div></div><div>I sounds like you disabled optimizations, and now optimizations are missing. The fast register allocator tries very hard to be fast. That includes producing suboptimal code. Sometimes it is faster to spill than to run an expensive interference computation.</div>
<div class="im"><div><br></div><blockquote type="cite"><div style="WORD-WRAP:break-word"><div><div><span style="color:rgb(0,0,255);font-family:Arial;font-size:small">What's 
more, setting the GPR_CR class to 'not-spillable' would probably do the trick 
here as we basically do not want to do this, and I would not have to 
pre-allocate. But there is probably a better way, or?</span></div></div></div></blockquote><div><br></div></div><div>I am sorry, I simply don't understand what you are asking for. You might as well suggest that we all don't pay taxes. It sounds tempting, but the plan needs some details.</div>
<div><br></div><div>If the fast register allocator is not working for you, you can use the greedy register allocator in -O0 builds by passing -regalloc=greedy. It's not that much slower.</div><div class="im"><div><br>
</div><blockquote type="cite"><div style="WORD-WRAP:break-word"><div><span><font face="Arial" color="#0000ff">I take 
it then that it is not possible to write operand-combinations as in GCC in LLVM 
so as to handle register pairing on a high level?</font></span></div></div></blockquote><div><br></div></div><div>That's right.</div><div class="im"><br><blockquote type="cite"><div style="WORD-WRAP:break-word">
<div><span> </span><span><font face="Arial" color="#0000ff">The PBQP 
algorithm as such supports register pairing per the article, but it 
was not implemented in RegAllocPBQP.cpp as far as I can see.</font></span></div>
<div><span><font face="Arial" color="#0000ff"></font></span></div></div></blockquote><div><br></div></div><div>The PBQP allocator allows targets to specify complicated constraints that the normal constraint model doesn't support. Constraints are modeled as matrices, so any specific type of constraint wouldn't be mentioned in the source file.</div>
<div class="im"><div><br></div><blockquote type="cite"><div style="WORD-WRAP:break-word"><div><span style="color:rgb(0,0,255);font-family:Arial;font-size:small">PBQP 
extension (suggestion)</span></div>
<div><span><font face="Arial" color="#0000ff">======================</font></span></div>
<div><span><font face="Arial" color="#0000ff"></font></span> </div>
<div><span><font face="Arial" color="#0000ff">Tablegen:</font></span></div>
<div><span><font face="Arial" color="#0000ff"></font></span> </div>
<div><span><font face="Arial" color="#0000ff">def 
regPair : registerPair<AddrReg0, OffsReg0>,</font></span></div>
<div><span><font face="Arial" color="#0000ff">~or~</font></span></div>
<div><span><font face="Arial" color="#0000ff">def 
regPair:  registerPairing<AddrReg0, [OffsReg0, OffsReg1, 
OffsReg2]>;</font></span></div>
<div><span><font face="Arial" color="#0000ff">~or~</font></span></div>
<div><span><font face="Arial" color="#0000ff">??</font></span></div></div></blockquote><div><br></div></div><div>I am not sure how much easier that would be than the current approach. I'll leave that up to Lang.</div>
<div class="im"><div><br></div><blockquote type="cite"><div style="WORD-WRAP:break-word"><div><span><font face="Arial" color="#0000ff">I 
beleive this should work by setting the cost to infinity for illegal 
combinations. </font></span><span><font face="Arial" color="#0000ff">I supervised a bacheolor student here last year 
</font></span><span><font face="Arial" color="#0000ff">(Jakob Stengård), and as far as I recall, Lang was interested in 
helping him getting this implemented</font></span></div>
<div><span><font face="Arial" color="#0000ff">then, 
although Jakob ran out of time. Has anything changed since then? 
</font></span><span><font face="Arial" color="#0000ff">What is your estimation on the amount of  </font></span><span><font face="Arial" color="#0000ff">work for this? 
Would anyone (Lang?) be willing to supervise it?</font></span></div></div></blockquote></div></div><br></div></blockquote></div><br></div>