[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
Kirill, you are correct WRT propagation of "b" for "i".  Prior to DOM1 we have:

;;   basic block 3, loop depth 1, count 0, freq 9100, maybe hot
;;    prev block 2, next block 4, flags: (NEW, REACHABLE)
;;    pred:       7 [91.0%]  (TRUE_VALUE,EXECUTABLE)
  if (i_1 == b_6(D))
    goto <bb 4>;
  else
    goto <bb 5>;
;;    succ:       4 [0.0%]  (TRUE_VALUE,EXECUTABLE)
;;                5 [100.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 4, loop depth 1, count 0, freq 2, maybe hot
;;    prev block 3, next block 5, flags: (NEW, REACHABLE)
;;    pred:       3 [0.0%]  (TRUE_VALUE,EXECUTABLE)
  g_x[i_1] = *x1_7(D);
  goto <bb 6>;
;;    succ:       6 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 5, loop depth 1, count 0, freq 9098, maybe hot
;;    prev block 4, next block 6, flags: (NEW, REACHABLE)
;;    pred:       3 [100.0%]  (FALSE_VALUE,EXECUTABLE)
  g_x[i_1] = *x2_9(D);
;;    succ:       6 [100.0%]  (FALLTHRU,EXECUTABLE)


DOM records that i_1 and b_6 are equivalent on the edge bb3->bb4.  So in bb4 it
replaces i_1 with b_6.  Presumably that's causing problems downstream in the
optimization pipeline.  The easiest way to think about this is we record that
i_1 can be legitimately replaced with b_6 in that context.  We could just have
easily recorded that b_6 can be replaced with i_1.

I don't think we have any heuristics for which of those two equivalences to
record, it's strictly based on the order of appearance (which is likely
determined elsewhere by canonicalization rules).

If you want to propose some heuristics, I'm all ears.   One might be to put the
object with the least number of references on the lhs.  THe idea would be to
try and ultimately get that use count to 0/1 which may allow that object to die
at the comparison.  There may be some reasonable heuristic around loop depth of
the names as well.    ie, do we want to replace uses of a non-loop object with
a loop object or vice versa?

Anyway, open to suggestions here...