https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|law at redhat dot com |rguenth at gcc dot
gnu.org
Summary|[6.0 regression] FAIL: |[6 Regression] FAIL:
|gcc.dg/tree-ssa/20030922-2. |gcc.dg/tree-ssa/20030922-2.
|c scan-tree-dump-times dom1 |c scan-tree-dump-times dom1
|"if " 2 |"if " 2
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So on x86_64 ifcombine has "removed" the if but after dom1 we still have
_14 = *_13;
if (_8 != _14)
goto <bb 3>;
else
goto <bb 5>;
<bb 3>:
target_bb.1_15 = target_bb;
_16 = _8 != target_bb.1_15;
_17 = _14 == target_bb.1_15;
_18 = _16 & _17;
if (_18 != 0)
which shows that running ifcombine before DOM might not be the best idea.
It also shows that the testcase should disable ifcombine to really test what it
was supposed to test. And then it also fails on x86_64.
VRP does optimize this case because it has a more powerful way to track
equivalences (and does a quadratic job in trying to simplify compares using
all equivalences of the lhs vs all equivalences of the rhs).
Which is another hint at the fact that DOM maybe shouldn't treat equivalences
derived from conditionals in the SSA_VALUE table where you can't really record
both _14 = target_bb.1_15 and target_bb.1_15 = _14 (which would get you a
nice cycle there).
For the existing way of DOM handlign this I don't see anything in the testcase
that could be used to build a new heuristic (in fact another heuristic
would say that what we do now is good -- _14 dies at the point where we
build the equivalency, target_bb.1_15 does not, so we don't want to propagate
_14 because that will increase its lifetime!)
I suggest to "fix" the testcase and XFAIL it. I'll take care of that.
