This is the mail archive of the 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]

[vta,vta4.4,trunk,4.4] fix -O0 -g vs -g0 codegen regression

If we drop decls from lexical blocks when not optimizing, we get codegen
differences, that -fcompare-debug testsuite runs in the vta branches

The problem is that cfgexpand expands variables that are not mentioned
in lexical blocks first, and those that are afterwards.  So, once we
remove the decl, we change the stack frame layout.  Offset changes
aren't significant in general, but if the frame is large enough, on
architectures that require different code for wider SP offsets, which in
turn might require more complex branches in the compiler, the
differences would be more visible at the compiler level.

Regardless, changing the layout of the stack frame is not something we'd
like to do, as it might introduce or remove bugs depending on -g.

This patch fixes it by avoiding, when not optimizing, the removal of
unused declarations from lexical blocks, as well as the lexical blocks
containing them.  Since we're not optimizing, we don't remove the decls
from the local decls list anyway, so I doubt this removal would have
saved a significant amount of memory.

I'm installing this in vta4.4 and vta branches.  Ok for trunk and 4.4?
This is a regression from 4.3.

for  gcc/ChangeLog.vta
from  Alexandre Oliva  <>

	* tree-ssa-live.c (remove_unused_scope_block_p): Don't remove
	unused declarations when not optimizing.

Index: gcc/tree-ssa-live.c
--- gcc/tree-ssa-live.c.orig	2009-05-15 04:51:06.000000000 -0300
+++ gcc/tree-ssa-live.c	2009-05-15 04:52:12.000000000 -0300
@@ -517,6 +517,13 @@ remove_unused_scope_block_p (tree scope)
 		&& ann->used)
 	unused = false;
+      /* Removing declarations, when we're not optimizing, is going to
+	 affect the order in which variables are expanded, causing
+	 codegen differences we ought to avoid.  We can't even remove
+	 the blocks, for the same reason.  */
+      else if (!optimize)
+	unused = false;
       /* When we are not doing full debug info, we however can keep around
 	 only the used variables for cfgexpand's memory packing saving quite
 	 a lot of memory.  

Alexandre Oliva, freedom fighter
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

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