[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:
http://gcc.gnu.org/ml/gcc-bugs/2002-05/msg00897.html
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
operands)
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
ebotcazou@multimania.com
-------------- 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