[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-01-12 12:36 --- (In reply to comment #17) > Can you point me to those? PR25643 and PR25145 . Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-12 12:29 --- Can you point me to those? I still think we should separate VRP of constant and symbolic ranges. For symbolic stuff we eventually want to utilize a theorem prover. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #16 from pinskia at gmail dot com 2008-01-12 12:26 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code > --- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-12 10:49 > --- > I think symbolic substitutions should be only done if the resulting stmt can > be simplified to a constant. Now for VRP my long-term plan is to get rid of > symbolic ranges altogether to make it cheaper and easier to keep value-range > information across passes. Actually I think it is wrong to get rid of symbolic ranges. I have filed a couple of bugs about adding more symbol ranges with respect of VRP. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-12 10:49 --- I think symbolic substitutions should be only done if the resulting stmt can be simplified to a constant. Now for VRP my long-term plan is to get rid of symbolic ranges altogether to make it cheaper and easier to keep value-range information across passes. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #14 from sebpop at gmail dot com 2008-01-12 00:11 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00518.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[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 changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-08-27 21:48:05 |2008-01-11 22:27:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #13 from spop at gcc dot gnu dot org 2008-01-10 00:09 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code For fixing this bug, one option is to disable symbolic propagations, as in the patchlet that I sent before, and also in the DOM pass. We have to show that there is no value in doing these transformations. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #12 from steven at gcc dot gnu dot org 2007-12-16 23:17 --- Open regression with no activity since February 14. Ping? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- 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
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
