[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-04-28
 CC||law at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Fixed by Jeffs later patch?

[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917

Jeffrey A. Law law at redhat dot com changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
 if (_8 != _14)
goto bb 3;
  else
goto bb 6;

  bb 3:
  target_bb.1_15 = target_bb;
  if (_14 == target_bb.1_15)
goto bb 4;
  else
goto bb 6;

  bb 4:
  if (_8 != target_bb.1_15)
goto bb 5;
  else
goto bb 6;


Presumably depending on the ordering in the conditionals, we should discover
that in bb4 _8 and _15 are equal and eliminate the test.

[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917

Andreas Schwab sch...@linux-m68k.org changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Andreas Schwab sch...@linux-m68k.org ---
r222492 is still failing.

[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917

--- Comment #4 from Jeffrey A. Law law at redhat dot com ---
We'll probably need to XFAIL this for now.

This is definitely a case where we were just getting lucky before and the new
code to canonicalize the comparison arguments causes us not to get lucky.

The single use heuristic doesn't help here, because both operands have multiple
uses.

I'd pondered walking up the use-def chains to guess which operand is more
expensive to compute and use that as a heuristic as well, but in this case it'd
do the opposite of what we want.

I don't see other obvious heuristics that would resolve this issue.

The right way to fix this would be to unify cprop and simplification -- ie,
when we have a statement that references an SSA_NAME with one of these
equivalences, we need to try both SSA_NAMEs and see if it simplifies.  I've
avoided doing that simply because it hasn't seemed worth the effort and
compile-time cost.