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: [patch] for PR18463


Helol,

> > > > > Sebastian's recent changes to chrec_convert cause this testcase (as well
> > > > > as some of spec benchmarks) regress on i686.  The reason is the
> > > > > following.  We have loop (obtained by expanding pointer arithmetics) like
> > > > > 
> > > > > unsigned i, j;
> > > > > float *p, *a, *o;
> > > > > 
> > > > > for (i = 0; i < n; i++)
> > > > >   {
> > > > >     j = 4 * i;
> > > > >     o = (float *) j;
> > > > >     p = a + o;
> > > > > 
> > > > >     *p = something;
> > > > >   }
> > > > > 
> > > > > With the changes to chrec_convert, since we cannot prove that j does not
> > > > > wrap, we set the evolution of o to chrec_dont_know. 
> > > > 
> > > > 
> > > > Actually, scev_probably_wraps_p should return "doesn't wrap" for this
> > > > case, because pointers don't wrap and the only use of this variable is
> > > > in pointer arithmetic.
> > > 
> > > Just a followup.
> > > 
> > > We *do* actually determine it doesn't wrap when you give it the
> > > statement.
> > 
> > the patch below as it is written is not a good idea, IMHO (assuming it
> > works the way I would expect it to). 
> 
> Just out of curisoity, why would you expect it to not propagate around
> until it got the right answer, instead stopping when it gets the wrong
> one?

I don't understand what you mean.  Could you please explain?

> Anyway, the real solution is to not have our regular pointer arithmetic
> to access the arrays like we do, since we know the pointer arith can't
> wrap, even if other stuff can.

Yep; the MEM_REFs patch (in whatever incarnation is current) should
definitely help.

Zdenek


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