Re: [avr-gcc-list] Pointer register allocation optimizer

[Georg-Johann Lay]

Wouter van Gulik schrieb:

Hi list,

This code:

char* f(char* p)
{
  p++;
  return p;
}

Results in:

mov r18,r24
mov r19,r25
subi r18,lo8(-(1))
sbci r19,hi8(-(1))
mov r24,r18
mov r25,r19
ret

When compiling with avr-gcc -O[23s] -mmcu=avr5 -S main.c
Which is bad since it could have been:

adiw r24, 1
ret

I tested against WinAVR's 4.3.3 and avr-gcc-4.7-185693-mingw32
Both generate the same code.

Should I create a bug report?

Wouter


Looks very much like PR52278, which is still open.

According to Vladimir, the register allocator (RA) should work smooth
with SUBREGs, but obviously, it does not.

Maybe it's also related to PR49491, yet another RA optimization flaw
showing up for avr.

You can try -fno-split-wide-types, but that might have other disadvantages.

Johann

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] Pointer register allocation optimizer

[Wouter van Gulik]

Georg-Johann Lay schreef op 2012-07-27 16:06:

Wouter van Gulik schrieb:

Hi list,
This code:
char* f(char* p)
{
  p++;
  return p;
}
Results in:

mov r18,r24
mov r19,r25
subi r18,lo8(-(1))
sbci r19,hi8(-(1))
mov r24,r18
mov r25,r19
ret
When compiling with avr-gcc -O[23s] -mmcu=avr5 -S main.c


Oops, copy paste error; for avr5 movw is used to move the pointer 
registers. Still it does a useless move.




Looks very much like PR52278, which is still open.



I think this is the same, for sanity I also checked with int and long 
(against my Ubuntu gcc-avr 4.5.3) and it yields the same result; first 
move the register then the add, then move it back.


What I wonder: why is r18 picked? Clearly r26, or r30 are way better 
choices. Maybe this is fixed in 4.7.1 already, don't have a 4.7+ at the 
moment.



According to Vladimir, the register allocator (RA) should work smooth
with SUBREGs, but obviously, it does not.



Clearly.

You can try -fno-split-wide-types, but that might have other 
disadvantages.




That gives the expected result.


HTH,

Wouter

___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list