This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]