[PATCH] Fix PR optimization/6713

Eric Botcazou ebotcazou@libertysurf.fr
Mon Jun 17 13:12:00 GMT 2002

I build up the following analysis on Glen Nakamura's findings:

insn 482 should have been deleted by cse.c:delete_trivially_dead_insns
under normal circumstances, i.e if insn 482 was either:
- a "regular" SET insn that defines a giv (i.e not via a NOTE), or
- a SET insn that defines a giv via a NOTE, but with a SET_SRC not being
itself another giv that gets combined with the first one.

Now the situation is the following when loop_optimize is called for
the first time:

insn #1:  giv2 <-- (biv+1)
insn #2:  giv1 <-- giv2 (REQ_EQUAL: (biv+1))
insn #3:  biv  <-- giv1

GCC is smart enough to detect that:
- the biv is incremented by 1 at insn #3,
- giv2 can be combined ("replaced") with giv1,
- the biv can be eliminated.

Actually giv2 is not directly "replaced" by giv1, but both are merged
into a third register, giv3, in the following way:
- giv3 is moved to giv1 with a new instruction:

insn #1:  giv2 <-- (biv+1)
insn #2:  giv1 <-- giv2 (REQ_EQUAL: (biv+1))
insn #4:  giv1 <-- giv3
insn #3:  biv  <-- giv1

I think the code expects insn #2 to be deleted by
delete_trivially_dead_insns, but...

- giv2 is scheduled to be replaced by giv3 at the end of the pass (only SRC

insn #1:  giv2 <-- (biv+1)
insn #2:  giv1 <-- giv3 (REQ_EQUAL: (biv+1))
insn #4:  giv1 <-- giv3
insn #3:  biv  <-- giv1

delete_trivially_dead_insns deletes insn #1, but not insn #2, likely because
of the note:

insn #2:  giv1 <-- giv3 (REQ_EQUAL: (biv+1))
insn #4:  giv1 <-- giv3
insn #3:  biv  <-- giv1

The proposed fix is to explicitly delete insn #2 when issuing insn #4.
Bootstrapped/regtested (C/C++) on i586-pc-linux-gnu (gcc-3_1-branch).

2002-06-17  Eric Botcazou <ebotcazou@multimania.com>
            Glen Nakamura <glen@imodulo.com>

 PR optimization/6713
 * loop.c (loop_givs_rescan): Explicitly delete the insn that
 sets a non-replaceable giv after issuing the new one.

Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loop.diff
Type: application/octet-stream
Size: 1121 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20020617/f073e345/attachment.obj>

More information about the Gcc-patches mailing list