https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124809
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
ick. We don't remove relations once they are added. Never been a need.
IN this program we have:
a.0_1 = a;
_2 = (int) a.0_1;
_3 = (int) g_16(D);
_4 = _2 != _3;
_20 = (short unsigned int) _4;
if (a.0_1 != _20)
goto <bb 4>; [5.50%]
else
goto <bb 6>; [94.50%]
<bb 4> [local count: 55807731]:
j_18 = a.0_1 + _20;
k_19 = (int) j_18;
if (a.0_1 == 0)
goto <bb 5>; [50.00%]
else
goto <bb 11>; [50.00%]
<bb 5> [local count: 27903866]:
_21 = k_19 >> _2;
goto <bb 11>; [100.00%]
<bb 6> [local count: 958878295]:
<<--- Partial equivalence
if (d.10_9 != 0)
goto <bb 7>; [50.00%]
else
goto <bb 8>; [50.00%]
at some point we register a partial equivalence of 16 bits between a.6_5 and
a.0_1
(Partial equivalences are also used between values of the same precision but
with difference signs as it represents a 16 bit equivalence, not a value.)
DOM continues omn its merry way, and decides at some point that on the else
side of
if (a.0_1 != _20)
that a.0_1 == _20, and as thats the only way to reach bb6, it rewrites that
statement
Optimizing block #6
1>>> STMT 1 = a.0_1 le_expr _20
1>>> STMT 1 = a.0_1 ge_expr _20
1>>> STMT 1 = a.0_1 eq_expr _20
1>>> STMT 0 = a.0_1 ne_expr _20
0>>> COPY a.0_1 = _20
Optimizing statement a.6_5 = (short int) a.0_1;
Replaced 'a.0_1' with variable '_20'
The next time ranger processes that statement, it registers a partial (bit)
equivalence between
a.6_5 and _20
but we do NOT delete the previous one... which means we now think that there is
an equivalence between a.6_5, _20, and a.0_1
Which there is not. Only one of those equivalences with a.6_5 can exist.
Either the old one needs to be deleted, or the new one not added.
I'm thinking about it...?
