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: "Jiangning Liu" <jiangning dot liu at arm dot com>
- To: "'Richard Guenther'" <richard dot guenther at gmail dot com>
- Cc: "Michael Matz" <matz at suse dot de>, <gcc at gcc dot gnu dot org>
- Date: Thu, 5 Jan 2012 16:34:15 +0800
- 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>
> >> > 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? 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?
Thanks,
-Jiangning