[Bug tree-optimization/79460] gcc fails to optimise out a trivial additive loop for seemingly arbitrary numbers of iterations

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 14 Feb 2017, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460
> 
> --- Comment #10 from amker at gcc dot gnu.org ---
> (In reply to Jakub Jelinek from comment #9)
> > (In reply to rguenther@suse.de from comment #8)
> > > On Tue, 14 Feb 2017, jakub at gcc dot gnu.org wrote:
> > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460
> > > > 
> > > > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > > > Shouldn't it (both in the vectorizer and in scev) be dependent not just on
> > > > flag_fp_contract_mode but also on some -ffast-math subflag?  Doing several
> > > > additions can e.g. raise different exceptions and have different roundings from
> > > > doing it as just one multiply.
> > > 
> > > Maybe, but I don't see which (apart from flag_unsafe_math_optimizations
> > > of course but we'd want to get rid of that...).  reassoc uses
> > > flag_unsafe_math_optimizations (and does this for SCALAR_FLOAT_TYPE_P
> > > only).  The docs only mention FMA for fp-contract...
> > 
> > fp-contract is I believe only about whether you are allowed to transform x =
> > a + b * c; into a FMA or not (or similar expressions), so I think isn't even
> > related to this.  Even if we want to get rid of
> > flag_unsafe_math_optimizations eventually, it is better to use that if we
> > don't know what exactly rather than emit wrong-code with -fno-fast-math,
> > we'll have to eventually add some new flags or figure it out.
> 
> I also think we need flag_unsafe_math_optimizations or similar on this, this is
> risky transformation and we may put iterative numerical algorithms in danger.

And here's that unroll heuristic patch (cleaned up a bit), it makes us
consider all operations on constants (where SCEV can compute an evolution)
as constant (and actually also folds them in the poor-mans cprop code).
Only works up to 16 iterations of course (thus for the testcase for
an upper bound of 16*4).  Kind of unrelated to this PR of course.

Index: gcc/tree-ssa-loop-ivcanon.c
===================================================================
--- gcc/tree-ssa-loop-ivcanon.c (revision 245417)
+++ gcc/tree-ssa-loop-ivcanon.c (working copy)
@@ -157,8 +157,6 @@ struct loop_size
 static bool
 constant_after_peeling (tree op, gimple *stmt, struct loop *loop)
 {
-  affine_iv iv;
-
   if (is_gimple_min_invariant (op))
     return true;

@@ -189,11 +187,9 @@ constant_after_peeling (tree op, gimple
     }

   /* Induction variables are constants.  */
-  if (!simple_iv (loop, loop_containing_stmt (stmt), op, &iv, false))
-    return false;
-  if (!is_gimple_min_invariant (iv.base))
-    return false;
-  if (!is_gimple_min_invariant (iv.step))
+  tree ev = analyze_scalar_evolution (loop, op);
+  if (chrec_contains_undetermined (ev)
+      || chrec_contains_symbols (ev))
     return false;
   return true;
 }
@@ -1259,7 +1255,7 @@ propagate_constants_for_unrolling (basic

       if (! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (result)
          && gimple_phi_num_args (phi) == 1
-         && TREE_CODE (arg) == INTEGER_CST)
+         && CONSTANT_CLASS_P (arg))
        {
          replace_uses_by (result, arg);
          gsi_remove (&gsi, true);
@@ -1276,7 +1272,7 @@ propagate_constants_for_unrolling (basic
       tree lhs;

       if (is_gimple_assign (stmt)
-         && gimple_assign_rhs_code (stmt) == INTEGER_CST
+         && TREE_CODE_CLASS (gimple_assign_rhs_code (stmt)) == 
tcc_constant
          && (lhs = gimple_assign_lhs (stmt), TREE_CODE (lhs) == SSA_NAME)
          && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
        {