[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Byte values promoted to int when during compare
From: |
Dmitry K. |
Subject: |
Re: [avr-gcc-list] Byte values promoted to int when during compare |
Date: |
Sun, 18 Jul 2004 09:04:57 +1100 |
User-agent: |
KMail/1.5 |
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 .