[avr-gcc-list] Problem where R0 gets used

[Andrew Hutchinson]

I think I have found a bug with avr register allocation.

There does not appear to be anything that prevents R0 from being allocated.

This register is used as scratch register and is buried in backend 
assembler patterns (so gcc cannot see when it is used or not).

I was running tests and a few failed at -O0 optimisation. These were 
structures  passed down functions. Essential 8 byte long variable. So 
register usage was very high (a nightmare to debug). I had used my 
optimal register allocation that (probably) makes it easier for gcc to 
use more registers.

Anyway, to move the 8 byte blocks around stack, gcc did a byte move loop 
(horrible but what do you expect at -O0)
R0 got allocated to the byte.

R0=  *ptr1
*ptr2 = R0

Gcc used  R26 for both pointers, and it was reloaded from stack. So  it 
had something like  MOVW  r26,[r26] - which due to overlap, used R0

So R0 got trashed.

There will be other examples where this could happen as R0 is used is 
quite a few places to help assembler. However, it is most likely when 
registers are in high demand and are efficiently used - so as gcc or 
anything else gets better, this becomes more of a problem.

The other test failures I have involve similar structures and/or long 
long patterns.

I can only assume at this time that the same could happen to R1.

I looked at avr.c and avr.h etc and I cannot see any place where either 
r0 or R1 is given paticulary special treatment.  We do not prevent 
allocation (R0 and R1 are the last registers). We do not  reject it for 
storing byte data. It is declared as FIXED_REGISTER - which I will research.

Andy