PR 32044

[Bernd Schmidt <bernds_cb1 at t-online dot de>]

This is the PR that causes code of the form
        while (nsec >= NSEC_PER_SEC) {
                nsec -= NSEC_PER_SEC;
                ++sec;
        }
to be converted to a division by the tree loop optimizer.  That is a
performance regression; we can assume that the code is written that way
on purpose because the number of iterations is known to be small.  On
targets where no hardware division is available it could easily be two
orders of magnitude slower.  Despite that, and despite the fact that we
know the revision that caused this, it's been languishing as a P4
regression for months.

Reverting part of revision 122896, as in the patch below, cures the
problem.  I propose to apply this before 4.3 is out.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Index: tree-scalar-evolution.c
===================================================================
--- tree-scalar-evolution.c	(revision 131745)
+++ tree-scalar-evolution.c	(working copy)
@@ -2727,6 +2727,14 @@ scev_finalize (void)
   scalar_evolution_info = NULL;
 }
 
+/* Returns true if EXPR looks expensive.  */
+
+static bool
+expression_expensive_p (tree expr)
+{
+  return force_expr_to_var_cost (expr) >= target_spill_cost;
+}
+
 /* Replace ssa names for that scev can prove they are constant by the
    appropriate constants.  Also perform final value replacement in loops,
    in case the replacement expressions are cheap.
@@ -2813,13 +2821,10 @@ scev_const_prop (void)
 	continue;
 
       niter = number_of_latch_executions (loop);
-      /* We used to check here whether the computation of NITER is expensive,
-	 and avoided final value elimination if that is the case.  The problem
-	 is that it is hard to evaluate whether the expression is too
-	 expensive, as we do not know what optimization opportunities the
-	 the elimination of the final value may reveal.  Therefore, we now
-	 eliminate the final values of induction variables unconditionally.  */
-      if (niter == chrec_dont_know)
+      if (niter == chrec_dont_know
+	  /* If computing the number of iterations is expensive, it may be
+	     better not to introduce computations involving it.  */
+	  || expression_expensive_p (niter))
 	continue;
 
       /* Ensure that it is possible to insert new statements somewhere.  */