[Bug tree-optimization/43567] linear loop transform

["tjvries at xs4all dot nl" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #3 from tjvries at xs4all dot nl  2010-06-25 20:06 -------
Created an attachment (id=21008)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21008&action=view)
partially redoing the fix for bug 20612

The problem is in this piece of code in lambda_loopnest_gcc_loopnest:
...
      /* Create the new iv.  */

      standard_iv_increment_position (temp, &bsi, &insert_after);
      create_iv (newlowerbound,
                 build_int_cst (type, LL_STEP (newloop)),
                 ivvar, temp, &bsi, insert_after, &ivvar,
                 NULL);

      /* Unfortunately, the incremented ivvar that create_iv inserted may not
         dominate the block containing the exit condition.
         So we simply create our own incremented iv to use in the new exit
         test,  and let redundancy elimination sort it out.  */
      inc_stmt = gimple_build_assign_with_ops (PLUS_EXPR, SSA_NAME_VAR (ivvar),
                                               ivvar,
                                               build_int_cst (type, LL_STEP
(newloop)));

      ivvarinced = make_ssa_name (SSA_NAME_VAR (ivvar), inc_stmt);
      gimple_assign_set_lhs (inc_stmt, ivvarinced);
      bsi = gsi_for_stmt (exitcond);
      gsi_insert_before (&bsi, inc_stmt, GSI_SAME_STMT);
...

In case the loop header is copied (-ftree-ch), the second increment is in the
same block as the first increment:
...
  lnivtmp.6_13 = lnivtmp.6_20 + 1;
  lnivtmp.6_1 = lnivtmp.6_20 + 1;
  if (lletmp.8_21 >= lnivtmp.6_1)
...
indeed redundancy elimination sorts this out.

However, if the loop header is not copied:
...<bb 5>:
  i_11 = i_1 + 1;
  lnivtmp.2_19 = lnivtmp.2_5 + 1;

<bb 6>:
  # i_1 = PHI <0(2), i_11(5)>
  # lnivtmp.2_5 = PHI <0(2), lnivtmp.2_19(5)>
  lletmp.4_16 = n_4(D) + -1;
  lnivtmp.2_17 = lnivtmp.2_5 + 1;
  if (lletmp.4_16 >= lnivtmp.2_17)
...
the second increment is an extra increment, on top of the first one.

The patches fixes this, I'm not sure how minimal or efficient, but I did a
x86_64-unknown-linux-gnu bootstrap build and ran testsuites (gcc, objc,
gfortran, g++, libgomp, libstdc++, libjava, libmudflap, libffi) for r161295
and r161295+patch, with identical results.


-- 


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