This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Updating INSN_STMT records.
- From: Jan Hubicka <jh at suse dot cz>
- To: gcc-regression at gcc dot gnu dot org, gcc at gcc dot gnu dot org, rth at cygnus dot com
- Cc: jh at suse dot cz
- Date: Mon, 3 Jun 2002 17:04:16 +0200
- Subject: Updating INSN_STMT records.
- References: <200206031450.g53EoZB32399@maat.sfbay.redhat.com>
> powerpc-eabisim gcc.sum gcc.dg/debug/debug-1.c
> powerpc-eabisim gcc.sum gcc.dg/debug/debug-2.c
> powerpc-eabisim gcc.sum gcc.dg/uninit-A.c
> mips-elf gcc.sum gcc.dg/debug/debug-1.c
> mips-elf gcc.sum gcc.dg/debug/debug-2.c
> mips-elf gcc.sum gcc.dg/debug/debug-6.c
Hi,
I've looked at these and all appears to be caused by same problem - when
optimizing, compiler slowly suceeds to replace the original insns (with
STMT record) by new insns without it. Most common sources seems to be
relatively few - the instruction splitting/peepholing and if conversion.
What would you think about adding family of function
emit_insn_after_stmt/emit_insn_before_stmt and friends that do clone the
stmt from the passed instruction?
Once this patch is stabilized, I would like to proceed in same direction
to kill line number notes, so this isse needs to be solved "properly"
Note that the issue does not appear to be "so tragic" as it may look
from testsuite, since in all cases the lexical block is very small and
most of it's functionality just gets copied elsewhere. GCC with the
change now performs much better in the other cases, where large regions
are "melted together"
Honza