[Bug tree-optimization/61607] New: DOM missed jump threading and destroyed loops

[rguenth at gcc dot gnu.org]

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

            Bug ID: 61607
           Summary: DOM missed jump threading and destroyed loops
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Keywords: missed-optimization, wrong-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org, law at gcc dot gnu.org
            Blocks: 39612

>From the testcase in PR39612, if transformed by loop store motion according to
the proposed patch DOM fails to cleanup the code.  Testcase without that patch,
compile with -Os -fno-tree-fre

void foo(int *);
void f2(int dst[3], int R)
{
  int i, inter[2];
  _Bool inter0p = 0;
  _Bool inter1p = 0;
  for (i = 1; i < R; i++)
    {
      inter0p = 1;
      inter1p = 1;
    }
  if (inter0p)
    inter[0] = 1;
  if (inter1p)
    inter[1] = 1;
  foo(inter);
}

we get before DOM1

  <bb 2>:
  goto <bb 4>;

  <bb 3>:
  i_7 = i_1 + 1;

  <bb 4>:
  # i_1 = PHI <1(2), i_7(3)>
  # inter0p_2 = PHI <0(2), 1(3)>
  # inter1p_3 = PHI <0(2), 1(3)>
  if (i_1 < R_6(D))
    goto <bb 3>;
  else
    goto <bb 5>;

(the loop, with two flags)

  <bb 5>:
  # inter0p_13 = PHI <inter0p_2(4)>
  # inter1p_14 = PHI <inter1p_3(4)>
  if (inter0p_13 != 0)
    goto <bb 6>;
  else
    goto <bb 7>;

  <bb 6>:
  inter[0] = 1;

  <bb 7>:
  if (inter1p_14 != 0)
    goto <bb 8>;
  else
    goto <bb 9>;

  <bb 8>:
  inter[1] = 1;

  <bb 9>:
  foo (&inter);

and the tail with the jump threading opportunity.

DOM figures out that inter0p_2 and inter1p_3 are the same but fails to see
that inter0p_13 and inter0p_14 are.  More strangely it does

  Registering jump thread: (2, 4) incoming edge;  (4, 5) joiner;  (5, 7)
normal;
fix_loop_structure: removing loop 1
flow_loops_find: discovered new loop 2 with header 4

that is, doesn't perform any threading but still cancels the loop header
and thus causes loop meta-information to vanish (which is sort-of wrong-code?).

This blocks a fix for PR39612 (well, or makes it "incredibly" more difficult
because I'd have to implement the above transform manually, which I'd
eventually
do, but ...).