This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Fold x + x to x * 2
> > 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.
> Do you avoid eliminating -ftravp traps in the process? (E.g., x ==
> 230000000, c == -10, 32-bit signed integers, x * c overflows but x * (c +
> 1) doesn't.)
ummm... no I do not (neither does the code for optimizing
x * c1 + x * c2 to x * (c1 + c2), so I have at least some excuse for
not noticing it, but of course you are right, it might be better to
check for it (I am not really sure whether this is an issue; we
definitely should not create new overflows, but I am not that sure
about possibly eliminating them).
Well, the optimization may also create overflows -- x == 0, c == MAX_INT... --
we do not require x or c to be constant, so this might happen.