https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
There are a couple of things going on.
VRP understands casts perfectly well. If we were to run EVRP "earlier", we get
this fine in EVRP.
ie. with -fno-tree-forwprop
we get
<bb 2> :
n_4 = (unsigned int) m_3(D);
if (n_4 <= 2)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
<bb 3> :
_1 = (long unsigned int) n_4;
if (_1 > 3)
goto <bb 4>; [0.00%]
else
goto <bb 5>; [100.00%]
<bb 4> [count: 0]:
__builtin_abort ();
and that works out fine:
<bb 2> :
n_4 = (unsigned int) m_3(D);
if (n_4 <= 2)
goto <bb 3>; [INV]
else
goto <bb 4>; [INV]
<bb 3> :
_1 = (long unsigned int) n_4;
<bb 4> :
return;
With forwprop, we get the masking of the original value:
n_4 = (unsigned int) m_3(D);
if (n_4 <= 2)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
<bb 3> :
_7 = m_3(D) & 4294967295;
_8 = m_3(D) & 4294967292;
if (_8 != 0)
goto <bb 4>; [0.00%]
Ranger knows the range of m_3 on entry to BB3 is:
[0, 2][4294967296, 18446744069414584322]
we cant enumerate all the ranges that have [0,2] in the lower words, or there'd
just be too many subranges.
and sadly, if that code were instead:
_7 = m_3(D) & 4294967295;
_8 = _7 & 4294967292;
we would again get [0,2] for a range for _8. but no. someone thinks they are
smarter again. Why the heck don't we do that??
Another way Ranger is going to be able to figure this out would be when we
implement bitmask tracking along with ranges.
n_4 = (unsigned int) m_3(D);
if (n_4 <= 2)
goto <bb 3>; [INV]
in addition to [0, 2][4294967296, 18446744069414584322]
we'd should be able to track in addition the lower bit are masked with 0x03
The final option that may eventually handle this is the new equivalency
tracking slated for next release.
It will track n_4 as a "less precision" equivalence of m_3, and when thats is
tied in with the rangers knowledge that n_4 is [0,2], it should (hopefully) be
able to recognize that
_8 = m_3(D) & 4294967292;
brings m_3 into the same precision as n_4 and then use the value of n_4.
but we aren't there yet. Maybe we need an early early VRP pass.. right after
early optimizations before the IL gets mucked with too much :-P
