[LLVMdev] Register allocation of stack slots

[Dan Gohman]

On Mar 25, 2009, at 11:21 AM, Christian Sayer wrote:

> Hi all,
> for my target, the register allocator tends to make use of few (i.e.  
> it seems one single) registers when allocating stack slots to  
> registers. This happens only to function locals (allocas) -  
> allocation for e.g. function arguments passed by the stack work fine.
> For example, the debug output of the initialization of several stack  
> slots is the following:
>
> 1 :  entry:
> 2 :     %reg1074<def> = movC 0
> 3 :  Store:     store <fi#18>, 0, %R0<kill>
> 4 :  Remembering SS#18 in physreg R0
> 5 :     store <fi#18>, 0, %R0<kill>
> 6 :  Reusing SS#18 from physreg R0 for vreg1075 instead of reloading  
> into physreg R0
> 7 :     store <fi#9>, 0, %R0, Mem:ST(2,2) [sig5069_nl + 0]
> 8 :  Reusing SS#18 from physreg R0 for vreg1076 instead of reloading  
> into physreg R0
> 9 :     store <fi#8>, 0, %R0, Mem:ST(2,2) [sig5069_nc + 0]
> 10:     %R0<def> = movC 16384
> 11:  PhysReg R0 clobbered, invalidating SS#18
> 12:     store <fi#7>, 0, %R0<kill>, Mem:ST(2,2) [sig5069_re + 0]
> 13:  Remembering SS#18 in physreg R0
> 14:     %R0<def> = load <fi#18>, 0
>
> If I interpret the log correctly:
> -R0 is used to initialize the fi#18
> -R0 is used to initialize fi #8 and #9 as well
> -in line 10 and 12, another value is has to be used to init frame  
> objects. R0 is allocated again
> -in line 14, R0 has to be reloaded
>
> The target has 16 registers, why there is no other register used at  
> line 10?

There's not quite enough information here for us to see
what's going on here. Could you post more of the code?

>
> Interestingly, the post-RA-scheduler pass, which I turn on by  
> default, reassigns R1 for the constant 16384 at line 10. However,  
> the reload of fi#18 stays in the code.
>
> BTW, if someone could advise about the risks of using the apparently  
> unfinished post-RA-scheduler - we really need it especially for the  
> hazard recognizer, so it would be nice to be aware of known  
> problems...


There are currently no known functionality problems. It isn't
enabled by default because it doesn't make enough of a
difference on ordinary code, while it does take compile time.

It is unfinished, in the sense that it doesn't have all the
features one might want in a post-RA scheduler, and because
the way it tracks register liveness information has a lot of
room for improvement. However, it is usable.

Dan