This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: missed loop optimizations from loop induction variable copies
- From: Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>
- To: Rahul Kharche <rahul at IceraSemi dot com>
- Cc: gcc at gcc dot gnu dot org, sdkteam-gnu <sdkteam-gnu at IceraSemi dot com>, sebastian dot pop at amd dot com
- Date: Wed, 23 Sep 2009 12:37:16 +0200
- Subject: Re: RFC: missed loop optimizations from loop induction variable copies
- References: <4D60B0700D1DB54A8C0C6E9BE69163700B7F5FDB@EXCHANGEVS.IceraSemi.local>
Hi,
<snip>
> IVOpts cannot identify start_26, start_4 and ivtmp_32_7 to be copies.
> The root cause is that expression 'i + start' is identified as a common
> expression between the test in the header and the index operation in the
> latch. This is unified by copy propagation or FRE prior to loop
> optimizations
> and creates a new induction variable.
>
>
> Does this imply we try and not copy propagate or FRE potential induction
> variables? Or is this simply a missed case in IVOpts?
IIRC, at some point maybe year or two ago Sebastian worked on enhancing
scev to analyze such induction variables (thus enabling IVopts to handle them).
But it seems the code did not make it to mainline,
Zdenek