Re: [avr-gcc-list] optimizing multiplies with mixed sizes

[hanzl]

> Has any work been done on optimizing multiplies involving mixed sizes?
> It seems that gcc could do a better job.  The extra clr, mul, and add
> are kind of painful to see.

It is similar to situation discussed in June and July under subject "Byte
values promoted to int when during compare":

On 24 Jun 2004 I wrote:
>>>> unsigned char A,B; ... A & 15 != B ...
>
>>>  It seems that A is promoted to int before the binary & operation ?
>>>  But why?
>>
>> Because the C standard says so.
>
>And because the compiler was not clever enough ...
>... to optimize this back to byte-only operations?

On 17 Jul 2004 Matthew Arcus wrote:

>unsigned int get16(unsigned char *p)
>{
>  return (*p << 8) | *(p+1);
>}
>
>... ... ...
>
>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)?


Seems that in all these cases it would be nice to have something like
another RTL optimizer working on operations with bytes (see the cited
thread for suboptimal assembly generated by gcc for these examples).

I know very little of gcc internals, so I just guess now: Adding
another RTL optimizer at that place is probably very hard, but maybe
it would be possible to do it all in one RTL optimizer if conversion
to 8-bit operations were somehow done as a transformation in RTL?
(Waiting for comments shouting out how childish my idea is...)


Trying to use just bytes whenever possible might look like "too much
attention given to junk CPUs which do just bytes" but it is not - if
it fits in bytes, it can be done by MMX, so the AVR community shares
some (gcc related) interests with folks doing multimedia on big CPUs.


Or there may be quite another way to deal with multiplies involving
mixed sizes - compile C code using C++ compiler and use classes
instead of 'int' or 'char' or both. This way one could provide his own
operators for all combinations of sizes. However I am not sure there
is a sensible way to make these operators both assembly-coded and
inline (there will be register allocation issues).


Regards

Vaclav Hanzl