This is the mail archive of the gcc@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: A case exposing code sink issue



> -----Original Message-----
> From: Richard Guenther [mailto:richard.guenther@gmail.com]
> Sent: Thursday, January 05, 2012 5:32 PM
> To: Jiangning Liu
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: Re: A case exposing code sink issue
> 
> On Thu, Jan 5, 2012 at 9:34 AM, Jiangning Liu <jiangning.liu@arm.com>
> wrote:
> >> >> > In final value replacement, expression "&a + D.xxxx" can be
> >> figured
> >> >> out,
> >> >> > while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we
> >> should
> >> >> > lower
> >> >> > &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It seems GCC
> >> intends
> >> >> to
> >> >> > keep
> >> >> > &a[i_xxx] until cfgexpand pass.
> >
> > Richard,
> >
> > Thanks a lot for your explanation!
> >
> > Any comments for this question as well? Does GCC intends to keep &a[i]
> until
> > expand pass?
> 
> It's kept as it suits - it's shorter and easier to analyze (we know the
> implicit
> multiplication won't overflow)
> 
> > Any special reason? If I change CHREC algorithm, I see ivopt
> > would have done this lowering, so we wouldn't see &a[i] in expand
> pass. Any
> > hurt?
> 
> No, I think changing the CHREC algorithm is ok (I didn't look closely
> at
> your patch).  This is stage1 material though.

Actually I didn't send it out at all. :-) And I just send out a RFC here
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00236.html, can you have a
look?

> 
> Thanks,
> Richard.
> 
> > Thanks,
> > -Jiangning
> >
> >
> >
> >





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