> -----Original Message----- > From: Richard Guenther [mailto:richard.guent...@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....@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 > > > > > > > >
