This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A case exposing code sink issue
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Jiangning Liu <jiangning dot liu at arm dot com>
- Cc: Michael Matz <matz at suse dot de>, gcc at gcc dot gnu dot org
- Date: Thu, 5 Jan 2012 10:32:03 +0100
- Subject: Re: A case exposing code sink issue
- References: <Pine.LNX.4.64.1111251524280.26507@wotan.suse.de> <Pine.LNX.4.64.1111281403050.26507@wotan.suse.de> <4ef2e9b0.874a440a.6fec.1b2dSMTPIN_ADDED@mx.google.com> <CAFiYyc3-TaE5ZLNqyYrVr8a5sCgecmcXvN3fRAvZrGZjhLUrcA@mail.gmail.com> <4efc29e7.83c6e30a.3fd8.6d04SMTPIN_ADDED@mx.google.com> <CAFiYyc2CzUwL3Cxi6C4ze39-MNjN4-gKajVnYnxAghDoAecYRQ@mail.gmail.com> <4f056095.0b43d80a.48c6.7571SMTPIN_ADDED@mx.google.com>
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.
Thanks,
Richard.
> Thanks,
> -Jiangning
>
>
>
>