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.
