[Bug tree-optimization/113301] [12/13/14 Regression] Missed optimization: (1/(x+1))/2 => 0 since gcc-12

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Even then, I wonder why ranger doesn't figure this out.
> > (x+1u) <= 2 ? x : 0
> > must have a range [-1, 1] and [-1, 1] / [2, 2] range should be [0, 0], no?
> 
> its because there is no branch which is what drives ranger. At this point,
> we aren't quite smart enough to completely evaluate the 2 operands of a
> conditional as if they were actual  branches.
> ie
>     _1 = x_4(D) + 1;
>     _10 = (unsigned int) x_4(D);
>     _6 = _10 + 2;
>     _7 = _6 <= 2;
>     _2 = _7 ? _1 : 0;
> 
> if that were:
>   if (_6 <= 2)
>     _2 = _1
> we'd recalculate _1 with the condition being (_6 <= 2) and we come upwith
> [-1, 1] for _1 instead of varying.
> 
> I'll have to look at whats involved in enhancing the fold code to invoke
> GORI to reevaluate _1 if _7 is [1,1].   in theory is not too difficult... :-)

ah, its more complicated than that. we normally do this evaluation, but the
cond_expr is using _1.. if you trace back from _6 in the condition, _1 is not
in the dependency chain anywhere, so GORi cannot compute anything for it.  it
can compute that x_4 is [-2, 0]  but it doesnt see any connection between _6 in
the condition and _1.

the remaining question is whether this can be cheaply identified as a
recomputation.. in which case we could recompute _1 usin the [-2, 0] for x_4
and come up with [-1, 1] 

I'll have a look if we can easily invoke hte recompuation code the edges
evaluations use or nor