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

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

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