[Bug middle-end/58742] pointer arithmetic simplification

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742

--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 3 Feb 2014, glisse at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58742
> 
> --- Comment #26 from Marc Glisse <glisse at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #25)
> > VERSION=0 and VERSION=1 are the same speed for me now,
> 
> They aren't quite for me (2.5 vs 2.7) but
> 
> > VERSION=2 is a lot slower still.
> 
> that's the part I am concerned with here.
> 
> > Yeah, the issue is that while FRE does some expression simplification it
> > doesn't wire into a common gimple pattern matcher (something I'd like to
> > fix for 4.10).  That is, the simplification forwprop performs should be
> > done by FRE already.  See tree-ssa-sccvn.c:simplify_binary_expression.
> 
> Ah, ok, that makes sense. I assume it would also have basic CCP-like
> functionality (forwprop can create constants but doesn't always fold the
> resulting constant operations). Looking forward to that!
> 
> > > VRP2 is too late if we hope to vectorize, and in
> > > any case it fails to remove the range checks, because it is confused by the
> > > new shape of the loops (possibly related to PR 25643, or not). The VRP2
> > > failure looks funny with these consecutive lines:
> > > 
> > >   # ivtmp.80_92 = PHI <ivtmp.80_53(9), ivtmp.80_83(8)>
> > >   # RANGE [10101, 989898] NONZERO 0x000000000000fffff
> > >   _23 = ivtmp.80_92;
> > >   if (ivtmp.80_92 > 999999)
> > > 
> > > Really, we don't know that the comparison returns false?
> > 
> > Well, _23 is simply dead at this point and VRP computed _92 to be
> > varying.
> 
> Yes. I just meant that, as a hack, for 2 SSA_NAME defined in the same BB where
> one is a copy of the other, we could merge their range info (in both
> directions) and it might in this special case work around the fact that VRP2 is
> confused by the loop. But that would be too fragile and hackish.
> 
> > From the no-undefined-overflow branch I'd take the idea of adding op
> > variants with known no overflow.  That is, add MULTNV_EXPR, PLUSNV_EXPR,
> > MINUSNV_EXPR that can be used on unsigned types, too (you'd of course
> > have to define what overflow means there - if a - b does not overflow
> > then a + (-b) will - negate of x will always overflow if x is not zero).
> 
> Ah, yes, I'd forgotten about those. I always wondered if it is better to have
> many different tree codes or a single one with "options". Like MULT_EXPR with a
> parameter saying what happens on overflow: undefined, saturate, wrap, other
> (seems hard to handle "jump to this location" in the same). Or COMPARISON_EXPR
> with several bools telling what the return value is if a<b, a==b, a>b, one is
> NaN, and if it can raise exceptions (we don't have the corresponding 32 tree
> codes). Or the 5 DIV_EXPR variants (counting only integers). I guess it doesn't
> really matter.

It matters for convenience with existing code like fold-const.c
which takes decomposed expression trees.  You'd need to add a bunch
of flags there and pass them through appropriately.  Much easier
to encode it in enum tree_code directly.

Richard.