[LLVMdev] register allocation

Jakob Stoklund Olesen stoklund at 2pi.dk
Fri Jan 20 09:34:18 PST 2012


On Jan 20, 2012, at 6:40 AM, Jonas Paulsson wrote:

>  > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do?
>  
> 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
> have to be spilled, at least not on -O3.

And the register allocator is trying very hard not to do that, but sometimes it just isn't possible.

You have the choice between aborting compilation or inserting expensive spill code when that happens.

> 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
> this happened for some reason or other.

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.

> 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?

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.

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.

> 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?

That's right.

>  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.

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.

> PBQP extension (suggestion)
> ======================
>  
> Tablegen:
>  
> def regPair : registerPair<AddrReg0, OffsReg0>,
> ~or~
> def regPair:  registerPairing<AddrReg0, [OffsReg0, OffsReg1, OffsReg2]>;
> ~or~
> ??

I am not sure how much easier that would be than the current approach. I'll leave that up to Lang.

> I beleive this should work by setting the cost to infinity for illegal combinations. I supervised a bacheolor student here last year (Jakob StengÄrd), and as far as I recall, Lang was interested in helping him getting this implemented
> then, although Jakob ran out of time. Has anything changed since then? What is your estimation on the amount of  work for this? Would anyone (Lang?) be willing to supervise it?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120120/84f9a0ab/attachment.html>


More information about the llvm-dev mailing list