This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: loop optimizer naivety
- From: law at redhat dot com
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 22 Sep 2003 15:17:55 -0600
- Subject: Re: loop optimizer naivety
- Reply-to: law at redhat dot com
In message <200309222241.20092.ebotcazou@libertysurf.fr>, Eric Botcazou writes:
>Hi,
>
>The compiler emits wrong code in a POOMA-related testcase on the 3.3 branch
>(PR opt/12340) because the loop optimizer is a bit naive. It thinks that
>the sequence
>
>(insn 609 604 810 4 0x40a5565c (parallel [
> (set (reg:SI 173)
> (plus:SI (reg:SI 185)
> (const_int 1 [0x1])))
> (clobber (reg:CC 17 flags))
> ]) 146 {*addsi_1} (nil)
> (nil))
>
>(insn 810 609 610 4 (nil) (set (reg:SI 185)
> (reg:SI 173)) 38 {*movsi_1} (nil)
> (nil))
>
>...
>
>(insn 812 765 103 4 (nil) (set (reg:SI 185)
> (reg:SI 173)) 38 {*movsi_1} (nil)
> (nil))
>
>
>means that the biv (reg:SI 185) is incremented twice. The sequence is
>essentially the result of GCSE PRE.
>
>
>Is the loop optimizer not supposed to be fed with such a sequence in the
>first place or is it really, really naive?
Is there any path through the loop where insns 810 and 812 could both
execute? ie, can you get from insn 810 to 812 or vice versa without
going back to the top of the loop? If so, then PRE/LCM has mucked things up.
Jeff