[fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)

[peter green]

>
> Then a register is spilled, i.e. replace by a location in memory. This 
> may be possible without new registers:
>
> mov ireg30d,ireg29d    ->     mov ireg30d,[ebp-40]
>
> ... but in some cases a help register is needed:
>
> mov ireg30d,[ebp+20]   ->     mov ireg99d,[ebp+20]
>                               mov [ebp-40],ireg99d
>
> Should a new register is needed, register allocation is completely 
> restarted with the new code.
Thanks for the info.
>> My current suspiscion is that something is missing regarding handling 
>> of running out of VFP registers and it hasn't been noticed before 
>> because noone has tried to do what i'm doing (implementing a calling 
>> convention using VFP registers and then stress testing it) but i've 
>> no idea where to look in the sourcecode to confirm/refute that idea.
>
> It doesn't look like spilling happens in your example: I don't see 
> moves from/to the stack frame as temporary location.
My suspiscion was that the compiler was trying to spill but not actually 
generating any code to implement the spill.
>
> Perhaps the first thing to check is to add a breakpoint in 
> Tinterferencebitmap.setbitmap.
>
> The "versions" of s20 use superregister 50 and 70, so a setbitmap 
> (50,70) or (70,50) should be called at some point to tell the register 
> allocator both registers are active at the same time and cannot be 
> coalesced.
I added a debug writeln to setbitmap and it does seem to be being called 
with both 50,70 and 70,50. Full output is at http://pastebin.com/3jd8zNkh