Feature Request

[Dave Hudson]

Hi,

L C wrote:
> I'd like to request an option to disable the promotion of chars (signed 
> and unsigned) to ints when doing arithmetic calculations on them. I 
> realize this is non-ANSI standard, but it would be particularly valuable 
> when working with 8-bit processors such as the AVR. (Ie., big speed 
> boost and code size reduction).

I don't believe that this is necessary for the core of gcc - it can 
cause quite unexpected consequences for compiling ISO code and would 
lead to a lot of otherwise unecessary typecasting required in other code.

I had the same problem in the IP2022 backend and wrote some 
backend-specific code to deal with it.  The code causes zero extends and 
some sign extends to be split and then runs a propagation pass.  Where 
it identifies (for example) that the upper 16 bits of an operation can 
be simplified by knowing that one operand is 0x00 (or possibly 0xff in 
the sign-extended cases) then it simplifies the RTL back to an 8-bit 
form instead of its promoted 16-bit form.

In the 200 kBytes of object code that I regularly compile I'm only aware 
of a small number of instances and one generic class of problem where 
this solution doesn't fully simplify things as desired and they're only 
not done because the propagation pass does not do everything that it could.

The generic class of problem is where a function result is an 8-bit 
quantity because gcc will always promote the result to 16 bits.  I can 
live with this because it avoids problems with older source code but 
it's a little irritating when an already sign extended result is sign 
extended again.

Of course one advantage with the approach I took is that sometimes 
things that started out as 16-bit operations in the source code become 
simplified to a more efficient 8-bit form whereas a compile flag won't 
do this.

FWIW I'm not sure that the win is quite as large as you think - I've 
estimated the win from the code I wrote to be around 2% to 2.5%, and 
this on a codebase where every variable possible is 8 bits wide.  I've 
seen the biggest wins in situations where switch statements are 
converted from jump tables into if/else chains.  Of course with 
something like the IP2022 or AVR then such small improvements can look 
huge if it means getting an app to fit the memory space :-)


Regards,
Dave