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


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
>
>
>
>


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