I thought worth posting the fullest reason for this problem and why its not fixed. The promotion is done inside C front end according to C rules. This is an absolute that many have failed to get changed. The AVR specific backend does, however, do? some opportunistic optimizations to remove some of the bloat. Since may opportunities are buried inside 16 bit or wider operations the backend only copes with a few obvious ones. Not all possible combination of operations are spotted. There have been changes in the past to help with this and related problems. Specifically splitting wide types into smaller types. For example 32 bit logical operation and moves could be split apart allowing obviously redundant operations to be discarded using only byte level optimization. Without this splitting, optimization in the? backend has to deal with all possible instructions combinations with all sizes of operands - which quickly gets out of hand for anything other than some 16bit int. Splits cannot deal with carry related operations (add,sub,shift, multiply) since gcc RTL model cannot be accurately described these instructions.? There are also unsplittable operands assocaited with functions. With split wide types is used there is often a mixture of wide and narrow processing of values e.g. 4 byte level logical ops followed by 32 bit add and then 4 byte stores. This "mixed mode" complexity prevent other gcc optimisations from improving? code. In many situations, this lost optimisation is greater than that gained by splitting (you may note that disabling splitting is often used to produce smaller avr code!) Splitting has to be done late - after optimisations have minimised the code at the widest level (perhaps deleting uneeded 32 bit operations entirly.). This reveals another limitation.? The split byte level code also needs many of the standard optimization to be reapplied. Gcc does not permit backends to control optimization pass order. I have personally tried adding splitters for many operations (logical and some shifts) and reapplied propagation passes and achieved better code. But without the carry problem being solved together with an acceptable means to control ? RTL optimization passes the results are still imperfect. :-( Andy ---------------------------------------------- Sent from my Dingleberry wired device. -----Original Message----- From: Weddington, Eric <eric.wedding...@atmel.com> To: Ruud Vlaming <r...@betaresearch.nl>; avr-gcc-list@nongnu.org Sent: Fri, Aug 21, 2009 5:06 pm Subject: RE: [avr-gcc-list] char to int promotion in bitwise operators > -----Original Message----- > From: > avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of Ruud Vlaming > Sent: Friday, August 21, 2009 2:01 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] char to int promotion in bitwise operators > > I think it is about time that the compiler is extended Patches welcome. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
