[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code

[spop at gcc dot gnu dot org]

------- Comment #11 from spop at gcc dot gnu dot org  2007-10-19 21:54 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to
optimize code

Just looking again to this old bug...

The problem with VRP/DOM is that they just state equalities, and then
they apply the substitution without really looking at the direction in
which to apply the substitution: so half of the time the transform is
probably a win ;-)

If you look at the transform that VRP/DOM do for the original
testcase, i.e. with the condition:

      if (x != i)
        abort ();

this is harmful, as VRP/DOM decides to replace i by x in the induction
variable i = i + 1, and we end with a code that is harder to analyze
later on.  Now, after reversing the operands in the condition,

      if (i != x)
        abort ();

both VRP/DOM will just say let's replace x by i, and then everything
is okay, so it's a win ;-)

Here is a patch for VRP to avoid random substitutions of symbolic
expressions, although this might not be the best approach to solve
the problem.

Index: tree-vrp.c
===================================================================
--- tree-vrp.c  (revision 129493)
+++ tree-vrp.c  (working copy)
@@ -6000,7 +6000,8 @@ vrp_finalize (void)
   for (i = 0; i < num_ssa_names; i++)
     if (vr_value[i]
        && vr_value[i]->type == VR_RANGE
-       && vr_value[i]->min == vr_value[i]->max)
+       && vr_value[i]->min == vr_value[i]->max
+       && !symbolic_range_p (vr_value[i]))
       {
        single_val_range[i].value = vr_value[i]->min;
        do_value_subst_p = true;

DOM has a similar code, but is more intricated, and also probably more
careful sometimes, looking at the loop depth of the definition before
replacing it, for avoiding to undo a LICM.  I think that the code that
looks at the profitability of this transformation could be shared
between VRP and DOM.

Sebastian


-- 


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