This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Preliminary patch for PR23820 and PR24309


Hello,

> > > 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.

why does this patch help?  It seems to me that dce should not affect
vrp.

> Diego, would that be acceptable?  Any strong reason to have DCE after
> VRP?

Well, vrp may create dead code, so the having dce after vrp seems more
natural.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]