https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #3)
> it's odd that VRP doesn't optimize this though. VRP2 says
>
> Exported global range table:
> ============================
> i_6 : int ~[4, 4]
> bool foo (int i)
> {
> bool _3;
>
> <bb 2> [local count: 118111600]:
> if (i_2(D) == 4)
> goto <bb 3>; [97.00%]
> else
> goto <bb 4>; [3.00%]
>
> <bb 3> [local count: 955630224]:
>
> <bb 4> [local count: 118111600]:
> # i_6 = PHI <i_2(D)(2), 6(3)>
> _3 = i_6 != 0;
> return _3;
>
> but shouldn't ranger figure that i_2(D) != 0 && 6 != 0 is the same as
> i_2(D) != 0? Alternatively this could be sth for phiopt. PRE still
> sees the loop (I guess it was previously the one optimizing this)
Ranger itself isn't going to see that, All we can tell by ranges directly is
that it is ~[4, 4]. You have to look back at the def from the use to come to
this conclusion, so it would be a simplification or PHI-opt thing.
Curious question, if that was an 'if' instead of a return using _3, the
threader would probably thread the PHI away? ie:
<bb 4> [local count: 118111600]:
# i_6 = PHI <i_2(D)(2), 6(3)>
_3 = i_6 != 0;
if (_3 != 0)
goto <bb7>
else
goto <bb8>
I don't suppose there is any possible future enhancement that would let us
thread into returns like this? Or maybe its not common enough?
