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