https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124809
--- Comment #10 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #9) > (In reply to Andrew Macleod from comment #8) > > 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. > > Not sure if I follow the above correctly, but shouldn't there only > be a partial equivalence between a.6_5 (signed short) and a.0_1 > (unsinged short) and _20? And isn't that correct? > These are global equivalences... when we see a.6_5 = (short int) a.0_1; Its globally true that a.6_5 and a.0_1 are 16 bit identical. When it is re-written by DOM into a.6_5 = (short int) _20 And re-processed, the relation oracle now registers a global bit equivalence between a.6_5 and _20, which then transitively creates a global equivalence between a.0_1 and _20... THAT transitive equivalence is *not* global in nature. At the moment, they all share a partial equivalence set.. so there is no direct way to "disable" this feature. VRP never encounters this because ranger never revisits a statement once its is processed fully and rewriiten. It Looks like DOM is using it for constant propagation and is revisiting it after it rewrites the statement. This may also have something to do with the path ranger which DOM uses.. I'm not as familiar with how it sets and resets things... I'll get back to you in a bit. > > 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...?
