<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 20, 2012, at 6:40 AM, Jonas Paulsson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta content="MSHTML 6.00.6000.17098" name="GENERATOR">
<div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<div dir="ltr" align="left"><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2"> > </font></span>What exactly are you proposing? Why can't
you do what the PowerPC and Hexagon targets do?<font face="Arial" color="#0000ff" size="2"></font></div><div><font face="Arial" color="#0000ff" size="2"></font></div>
<div><font face="Arial" color="#0000ff" size="2"></font> </div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">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 class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">have
to be spilled, at least not on -O3.</font></span></div></div></blockquote><div><br></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><br></div><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"><div><div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">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 size="2"><font color="#0000ff"><span class="257413013-20012012">this happened for some reason or other.
</span></font></font></font></div></div></div></blockquote><div><br></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><br></div><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"><div><div><span class="Apple-style-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>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><br></div><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"><div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">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>That's right.</div><br><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<div><span class="257413013-20012012"> </span><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">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 class="257413013-20012012"><font face="Arial" color="#0000ff" size="2"></font></span></div></div></blockquote><div><br></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><br></div><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"><div><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: Arial; font-size: small; ">PBQP
extension (suggestion)</span></div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">======================</font></span></div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">Tablegen:</font></span></div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">def
regPair : registerPair<AddrReg0, OffsReg0>,</font></span></div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">~or~</font></span></div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">def
regPair: registerPairing<AddrReg0, [OffsReg0, OffsReg1,
OffsReg2]>;</font></span></div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">~or~</font></span></div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">??</font></span></div></div></blockquote><div><br></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><br></div><blockquote type="cite"><div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"><div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">I
beleive this should work by setting the cost to infinity for illegal
combinations. </font></span><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">I supervised a bacheolor student here last year
</font></span><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">(Jakob Stengård), and as far as I recall, Lang was interested in
helping him getting this implemented</font></span></div>
<div><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">then,
although Jakob ran out of time. Has anything changed since then?
</font></span><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">What is your estimation on the amount of </font></span><span class="257413013-20012012"><font face="Arial" color="#0000ff" size="2">work for this?
Would anyone (Lang?) be willing to supervise it?</font></span></div></div></blockquote></div><br></body></html>