This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/57488] [4.9 regression] loop terminates early at -O3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57488

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The fun thing is that this is a regular partial redundancy but requires
an earlier partial partial redundancy elimination to be performed.

So what happens is that

int v;
void foo (int n)
{
  int i, j;
  for (i = 0; i < n; ++i)
    for (j = 0; j < n; ++j)
      v++;
}

gets transformed to

int v;
void foo (int n)
{
  int i, j;
  for (i = 0; i < n; ++i)
    tem = v;
    for (j = 0; j < n; ++j)
      # PHI <tem, v>
      v = tem + 1;
}

and in the 3rd insert iteration this becomes

int v;
void foo (int n)
{
  int i, j;
  tem2 = v;
  for (i = 0; i < n; ++i)
    # tem2 = PHI <tem2, ...>
    tem = tem2;
    for (j = 0; j < n; ++j)
      # tem = PHI <tem, v>
      v = tem + 1;
}

with ... replaced by the value and representative 'tem' because via the
NEW sets we propagate that down to the latch.

Of course PRE works fine with the above simplified testcase ...

The following speedup patch fixes the bug:

Index: gcc/tree-ssa-pre.c
===================================================================
--- gcc/tree-ssa-pre.c  (revision 200237)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -3665,6 +3666,12 @@ insert (void)
       if (dump_file && dump_flags & TDF_DETAILS)
        fprintf (dump_file, "Starting insert iteration %d\n", num_iterations);
       new_stuff = insert_aux (ENTRY_BLOCK_PTR);
+
+      /* Clear the NEW sets before the next iteration.  We have already
+         fully propagated its contents.  */
+      if (new_stuff)
+       FOR_ALL_BB (bb)
+         bitmap_set_free (NEW_SETS (bb));
     }
   statistics_histogram_event (cfun, "insert iterations", num_iterations);
 }

remains to be seen why ... (I can only think of NEW sets propagated
over backedges requiring a 2nd iteration to make their effect visible)

That said, this bug seems to be latent for a long time.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]