This is the mail archive of the gcc-patches@gcc.gnu.org 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] Fix PR58143 and dups


On Thu, 17 Oct 2013, Jakub Jelinek wrote:

> On Thu, Oct 17, 2013 at 09:56:31AM +0200, Richard Biener wrote:
> > off-noise (more than 5s difference) may be 462.libquantum and 
> > 459.GemsFDTD.  I didn't include unpatched trunk in the comparison
> > (not fixing the bug isn't an option after all).
> > 
> > Conceptually I like the rewriting into unsigned arithmetic more
> > so I'm going to apply that variant later today (re-testing 3
> > runs of 462.libquantum and 459.GemsFDTD, this time with address-space
> > randomization turned off).
> 
> Can't we rewrite for the selected arithmetic operations and punt (is that
> what Bernd's patch did) on moving other arithmetics?  Well, there are
> operations that are safe even for signed types, e.g. rotates, isn't
> RSHIFT_EXPR also safe?
> Can't you handle also LSHIFT_EXPR (or do we treat it even signed as never
> undefined in the middle-end/backend?).

Sure, we can.  I concentrated on fixing the cases that later cause
issues with aggressively treating the ops during niter analysis
which means ops that SCEV handles (see 
tree-scalar-evolution.c:interpret_rhs_expr).

But I'd rather have testcases here ...

Teaching LIM how to move conditional code would also be nice.

Btw, I don't think we'd lose many optimization opportunities if
we for example don't treat signed shifts or division as invoking
undefined behavior on overflow.  All the overflow business is
important for loop optimizations and thus important only for
the cases that SCEV can handle ...

Richard.


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