Feature Request

[L C]

Thanks for the reply. I'd like to address some of your points, and 
hopefully this request will be considered...

1) I don't think the ISO code and unecessary typecasting issues would be 
a concern since the requested compiler switch would obviously not be the 
default. You would have to intentionally enable it and therefore realize 
the ramifications.
2) I'm an experienced hardware/firmware developer and I'm afraid I 
wouldn't have a clue how to write the backend code you are talking 
about. A simple compiler switch would simplify matters greatly.
3) I think for a typical simple embedded systems program the savings 
would be greater than your 2-2.5%. I changed one arithmetic calculation 
on my AVR such that I casted every calc back to unsigned char and the 
code to do the calculation went from about 14 bytes to 4. It would also 
be especially valuable in interrupt service routines where small code 
size is key.

I'd be interested in others' views and if I should be making this 
request elsewhere, please let me know. Thanks.


Dave Hudson wrote:

> 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
>
>