This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Put scope blocks on a diet


On Aug  6, 2007, Jan Hubicka <jh@suse.cz> wrote:

> I would like to test the attached patch.  It prevents the removal before
> inlining so UIDs should remain the same.  However I do get massive
> regressions on bootstrap-debug with or without the block removal code.
> I will now rebuild and see if the set of failing files changes by 
> disabling block removal, but if you do have some testcases handy, it
> would help.

> I wonder if we need to keep those at all - dwarf2 already uses abstract
> origin to avoid need to saveinfo on variables in each copy.  We can
> probably just keep around the dead variables on separate list in their
> ABSTRACT_ORIGIN -g or not?

This patch of yours (except for the ChangeLog entry) fixes the
-g-changes-generated-code in the trunk, so this should go in.

However, it breaks the vta branch, because we still keep debug
annotations for variables in blocks that your patch removes.  I
suppose I could just drop such annotations in the floor for now, but,
in the long run, should I?

for gcc/ChangeLog.vta
from  Jan Hubicka  <jh@suse.cz>

	* tree-ssa-live.c (remove_unused_scope_block_p): Drop
	declarations and blocks only after inlining.

Index: gcc/tree-ssa-live.c
===================================================================
--- gcc/tree-ssa-live.c	(revision 127183)
+++ gcc/tree-ssa-live.c	(working copy)
@@ -494,7 +495,11 @@ remove_unused_scope_block_p (tree scope)
 	 only the used variables for cfgexpand's memory packing saving quite
 	 a lot of memory.  */
       else if (debug_info_level != DINFO_LEVEL_NORMAL
-	       && debug_info_level != DINFO_LEVEL_VERBOSE)
+	       && debug_info_level != DINFO_LEVEL_VERBOSE
+	       /* Removing declarations before inlining is going to affect
+		  DECL_UID that in turn is going to affect hashtables and
+		  code generation.  */
+	       && cfun->after_inlining)
 	{
 	  *t = TREE_CHAIN (*t);
 	  next = t;
-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]