Re: A + B CMP A -> A CMP' CST' match.pd patterns [was [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)]

[Jeff Law <law at redhat dot com>]

On 01/23/2017 02:10 AM, Richard Biener wrote:
> I think it was added for the reason stated in the comment:
>
> /* When one argument is a constant, overflow detection can be simplified.
>    Currently restricted to single use so as not to interfere too much with
>    ADD_OVERFLOW detection in tree-ssa-math-opts.c.
>    A + CST CMP A  ->  A CMP' CST' */
> (for cmp (lt le ge gt)
>      out (gt gt le le)
>  (simplify
>   (cmp:c (plus@2 @0 INTEGER_CST@1) @0)
>   (if (TYPE_UNSIGNED (TREE_TYPE (@0))
>        && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))
>        && wi::ne_p (@1, 0)
>        && single_use (@2))
>    (out @0 { wide_int_to_tree (TREE_TYPE (@0), wi::max_value
>                (TYPE_PRECISION (TREE_TYPE (@0)), UNSIGNED) - @1); }))))
>
> > Certainly the easiest thing to do is remove the single use restriction. If
> > we ultimately don't want to do that, we can probably detect when the
> > transformation will allow the conditional to be eliminated in VRP and I
> > would claim that elimination of the conditional at compile time trumps the
> > other potential concerns here.  That's going to be uglier and essentially
> > duplicate parts of what match.pd does, but certainly doable -- I've even
> > prototyped it.
>
> Yeah, duplicating that sounds ugly.
So one possibility is to put an additional if case in the code above 
without the single_use condition which fires iff we're turning the two 
operand relational into a zero/not-zero test.

The only problem is that doesn't manage to clean things up until dom3. 
We could instead have them cleaned up by dom2 if the tweak is in VRP. 
This is because we don't call the gimple folders on the statement until 
after dom2 is already complete.

So there's 10 blocks of crud in the IL for the 40 passes between dom2 
and dom3.  And FWIW, this shows up a hundred times or so during a GCC 
bootstrap.  I haven't looked to see how many of those result in just a 
simplified test vs those with nice secondary optimizations like we see 
with the test in the BZ.


> But undoing it for the sake of detecting overflow builtins is as well (OTOH
> nothing does the reverse transform so if the user wrote the "simplified"
> variant we don't detect overflow either).
I'm not sure there'd be enough information left to undo the 
transformation, even if it were restricted to the zero/not-zero 
resulting test.

Jeff