From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27674 invoked by alias); 19 Oct 2007 21:54:27 -0000 Received: (qmail 27590 invoked by alias); 19 Oct 2007 21:54:13 -0000 Date: Fri, 19 Oct 2007 21:54:00 -0000 Message-ID: <20071019215413.27589.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "spop at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg01734.txt.bz2 ------- 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