This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [Patch,AVR]: PR49687 (better widening 32-bit mul)
> -----Original Message-----
> From: Georg-Johann Lay [mailto:avr@gjlay.de]
> Sent: Monday, July 25, 2011 10:29 AM
> To: Weddington, Eric
> Cc: gcc-patches@gcc.gnu.org; Anatoly Sokolov; Denis Chertykov; Richard
> Henderson
> Subject: Re: [Patch,AVR]: PR49687 (better widening 32-bit mul)
>
>
> This means that a pure __mulsi3 will have 30+30+20 = 80 bytes (+18).
>
> If all functions are used they occupy 116 bytes (-4), so they actually
> save a little space if they are used all with the benefit that they also
> can one-extend, extend 32 = 16*32 as well as 32=16*16 and work for
> small (17 bit signed) constants.
>
> __umulhisi3 reads:
>
> DEFUN __umulhisi3
> mul A0, B0
> movw C0, r0
> mul A1, B1
> movw C2, r0
> mul A0, B1
> add C1, r0
> adc C2, r1
> clr __zero_reg__
> adc C3, __zero_reg__
> mul A1, B0
> add C1, r0
> adc C2, r1
> clr __zero_reg__
> adc C3, __zero_reg__
> ret
> ENDF __umulhisi3
>
> It could be compressed to the following sequence, i.e.
> 24 bytes instead of 30, but I think that's too much of
> quenching the last byte out of the code:
>
> DEFUN __umulhisi3
> mul A0, B0
> movw C0, r0
> mul A1, B1
> movw C2, r0
> mul A0, B1
> rcall 1f
> mul A1, B0
> 1: add C1, r0
> adc C2, r1
> clr __zero_reg__
> adc C3, __zero_reg__
> ret
> ENDF __umulhisi3
>
>
> In that lack of real-world-code that uses 32-bit arithmetic I trust
> my intuition that code size will decrease in general ;-)
>
Hi Johann,
I would agree with you that it seems that overall code size will decrease in general.
However, I also like your creative compression in the second sequence above, and I think that it would be best to implement that sequence and try to find others like that where possible.
Remember that to AVR users, code size is *everything*. Even saving 6 bytes here or there has a positive effect.
I'll let Richard (or Denis if he's back from vacation) do the actual approval of the patch, as they are a lot more technically competent in this area. But I'm ok with the general tactic of the code reuse with looking at further ways to reduce code size like the example above.
Eric Weddington