This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

# Re: [patch] Fold x + x to x * 2

*From*: Paul Schlie <schlie at comcast dot net>
*To*: <gcc-patches at gcc dot gnu dot org>
*Date*: Sun, 07 Nov 2004 15:23:00 -0500
*Subject*: Re: [patch] Fold x + x to x * 2

> From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
>>> during investigation of PR 17549 I noted that we do not fold x + x to x
>>> * 2. We also do not fold x * c + x to x * (c + 1). (For non-floats.
>>> For floats we do both, under some assumptions.) In the case of PR
>>> 17549, the ivopts end up producing expressions of type x+x+...+x with as
>>> much as 8 operands (the expressions are then somehow folded in RTL
>>> optimizers, I think, so we do not end up producing these sums and it
>>> does not affect size of the final code, but still this behavior is quite
>>> weird). This patch implements these transformations.
>>
>> How is perceived that (2 * x) is preferable to (x + x), as in general
>> it's most likely not?
>>
>> even (x + x + x + x) would guess should likely only be target neutrally
>> folded to (t = (x + x), (t + t)), not (4 * x); where then based on the
>> target machine, likely to (x << 2) or (x * 4), but not before.
>>
>> Do I misunderstand?
>
> yes. x * 2 (or x * 4) is much easier to work with, possibly enabling
> further optimizations. You will obtain the fast to compute expressions
> you mention from it at the time rtl is produced (see
> choose_mult_variant/expand_mult_const).
>
> Zdenek
Thanks, understood, now realize the further relative importance of optimal
multiply rtl machine descriptions.