Re: [avr-gcc-list] Byte values promoted to int when during compare

[Dmitry K.]

As Matthew Arcus wrote:
>
> I was looking at the code generated for:
>
> unsigned int get16(unsigned char *p)
> {
>   return (*p << 8) | *(p+1);
> }
>
> which (target 8535, -Os) compiles to (comments inserted by myself):
>
>       movw r30,r24 // Copy parameter p (R24, R25) to Z register (R30 & R31)
>       ld r24,Z     // Load R24 indirect from Z
>       clr r25      // R25 = 0
>       mov r19,r24  // R19 = R24
>       clr r18      // R18 = 0
>       ldd r24,Z+1  // Load R24 indirect from Z+1
>       clr r25      // R25 = 0
>       or r18,r24   // R18 = R18 | R24, ie. R18 = R24, since R18 = 0
>       or r19,r25   // R19 = R19 | R25, ie. R19 = R19, since R25 = 0
>       movw r24,r18 // Move result (in R18/19) to return value register 
> (R24/25)
>       ret
>
> (the code for -O3 is similar).
>
> OK, so the copying to Z is necessary, since we only have a limited
> range of index registers that we can use, and we have to do the load
> indirects, but we should be able to simplify to something like:
>
>       movw r30,r24 // Copy parameter p (R24, R25) to Z register (R30 & R31)
>       ld r24,Z     // Load R24 indirect from Z
>       ld r25,Z+1   // Load R24 indirect from Z+1
>       ret
>
> The problem, I guess, is that the intermediate values are all 16-bit
> (since that's the size of an int on the AVR) and presumably are
> represented as 16-bit values in the RTL, where most of the
> optimization takes place, but the RTL optimizer doesn't know about the
> mapping of RTL registers to pairs of 8-bit registers, so we don't get
> the obvious optimizations happening.
>
> Is there any scope for adding some sort of optimization stage after the
> conversion to 8-bit register code that will get rid of some of this stuff
> (my knowledge of GCC internals is limited to a quick eyeballing of the
> relevant parts of the code)?
>
> Matthew.
>

I shall add, that here there is one more omission.  And this omission is 
typical for avr-gcc.  It is not connected to 8-bit length.  Why to not change 
places arguments of operation 'or'?  Compilation with an option '-fnew-ra' 
does it, but, first, in the documentation it is not recommended to use this 
option, and second, on real programs it increases the size of a code.

This is about avr-gcc 3.3.4 .