[LLVMdev] Register allocation of stack slots

[Dan Gohman]

On Mar 26, 2009, at 11:05 AM, Christian Sayer wrote:

> Dan,
>
> thanks for your hints about the post-RA scheduler.
>
> However, I have difficulties creating a reasonably small and concise
> testcase for the problem I described, and it's on my own target  
> anyway.
> In principle, I see the following:
>
> %theStruct = type { %theStruct2, %theStruct3, i16, ... }
>
> define void @f1(%theStruct* %tmp) {
>
> // initialize some locals
> %a= alloca i16, align 2
> store i16 1, i16* %a      ;similar b ...
> .
> .
>
> // GEP some pointers to elements of tmp
> %x = getelementptr %theStruct* %tmp, i64 0, i32 13    ; similiar  
> y,z...
> .
> .
>
> call void f2 (%theStruct2* %x, %theStruct2* %y, %theStruct3* %z,  
> i16* %a, i16* %b, ...)
>
> %var = getelementptr %theStruct* %tmp, i64 0, i32 7
> store i16 0, i16* %var
>
> ret void
>
> }
>
> Without the penultimate instruction (store something into the struct),
> registers for locals init like a, b, are allocated as I expect, i.e.  
> one for
> each constant (the architecture needs to do a mov and a store to  
> initialize memory).
> With these two instructions, the initialization of all the locals  
> are done using only
> one register, which results in reloads of locals just initialized  
> before.
>
> Well I don't know if it is possible to say anything about that, but  
> maybe someone
> has a clue?

Are you generating code with the "fast" option, or the equivalent? This
can cause a variety of code pessimizations.

Otherwise, it's hard to say.  The final store and its getelementptr are
keeping %tmp live across the call; without them no values are live
across the call, but I don't know what effect that has on your target.

Dan