This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Preliminary patch for PR23820 and PR24309
On 10/12/07, Sebastian Pop <sebpop@gmail.com> wrote:
> On 10/12/07, Sebastian Pop <sebpop@gmail.com> wrote:
> > True, if I'm dumping the value ranges that VRP ends with, we have
> >
> > N.0_28: [1, +INF] EQUIVALENCES: { N.0_8 } (1 elements)
> >
> > that is enough to deduce that "if (N != 0)" is true. I'm looking into
> > why VRP doesn't trigger the elimination of the condition.
> >
>
> That's really strange, as after first VRP we don't have any N!=0
> condition. I suppose that DCE is in fault there: in passes.c we have
> the following sequence around the first VRP:
>
> NEXT_PASS (pass_vrp);
> NEXT_PASS (pass_dce);
> NEXT_PASS (pass_cselim);
>
> Now if I'm duplicating VRP just after DCE,
>
> NEXT_PASS (pass_vrp);
> NEXT_PASS (pass_dce);
> NEXT_PASS (pass_vrp);
> NEXT_PASS (pass_cselim);
>
> the N!=0 in the outer loop disappears, and the ltrans-3.c testcase
> passes with the stricter definition of the perfect nested loop.
>
The following patch solves the problem. Diego, would that be
acceptable? Any strong reason to have DCE after VRP?
Sebastian
Index: passes.c
===================================================================
--- passes.c (revision 129276)
+++ passes.c (working copy)
@@ -567,8 +567,8 @@ init_optimization_passes (void)
NEXT_PASS (pass_forwprop);
NEXT_PASS (pass_copy_prop);
NEXT_PASS (pass_merge_phi);
- NEXT_PASS (pass_vrp);
NEXT_PASS (pass_dce);
+ NEXT_PASS (pass_vrp);
NEXT_PASS (pass_cselim);
NEXT_PASS (pass_dominator);
/* The only const/copy propagation opportunities left after