Re: [PATCH] Merge from LTO: eh_personality changes

[Richard Guenther <rguenther@suse.de>]

On Thu, 10 Sep 2009, Richard Guenther wrote:

> On Thu, 10 Sep 2009, Richard Guenther wrote:
> 
> > On Thu, 10 Sep 2009, Richard Guenther wrote:
> > 
> > > On Tue, 8 Sep 2009, Richard Henderson wrote:
> > > 
> > > > On 09/08/2009 08:20 AM, Richard Guenther wrote:
> > > > > > Ok.  I'll modify the patch to make this a true langhook and maybe move
> > > > > > the eh-personality also to a langhook called from eh lowering.
> > > > > 
> > > > > The latter is difficult as C++ is playing some tricks with Java vs.
> > > > > non-Java personality, so I leave that alone for now.
> > > > 
> > > > Ew.
> > > > 
> > > > > FYI the following two patches would implement the above (untested).
> > > > 
> > > > Looks good.
> > > 
> > > I've been playing a bit with optimizing setting of 
> > > DECL_FUNCTION_EH_PERSONALITY only if the function uses EH types
> > > instead of just checking for an empty EH region tree.  It doesn't look
> > > like its very simple - even a catch (...) needs a personality routine.
> > > 
> > > So I am now testing the following - the ERT_ALLOWED_EXCEPTIONS case
> > > is required to get diagnostics from g++.dg/torture/pr34850.C which
> > > requires inlining memset into clear_mem.
> > > 
> > > If that doesn't work out I'll refrain from optimizing at all and
> > > just disable cross different EH personality TU inlining completely
> > > (that already passed bootstrapping and testing, it would be
> > > -  if (function_needs_eh_personality (cfun))
> > > -    DECL_FUNCTION_PERSONALITY (current_function_decl) = 
> > > eh_personality_decl;
> > > +  DECL_FUNCTION_PERSONALITY (current_function_decl) = 
> > > eh_personality_decl;
> > > meaning no functional change as far as trunk is concerned)
> > 
> > Doesn't seem to work.  Instead I tried to fall back to
> > the gcc personality for detecting empty type lists, again setting
> > a cfi personality for all functions we emit.  But that doesn't work
> > either (it seems catch (...) doesn't work with the gcc personality,
> > g++.dg/eh/loop1.C fails).
> 
> Which would be the following patch.

On top of which the following seems to fix things.  Well "fix" in
that 1) C/C++ functions that do not need a personality don't get one,
thus a smaller .eh_frame, 2) we don't do invalid inlining 3) we still
inline enough.

Adjusting DECL_STRUCT_FUNCTION in tree_can_inline_p is of course a
hack, but well ... I don't feel like rewriting the inliner right now.

Hmm.  Testing in progress, results tomorrow.

Richard.

Index: gcc/except.c
===================================================================
--- gcc/except.c.orig	2009-09-10 17:47:02.000000000 +0200
+++ gcc/except.c	2009-09-10 17:14:25.000000000 +0200
@@ -4629,20 +4629,9 @@ function_needs_eh_personality (struct fu
 
 	case ERT_MUST_NOT_THROW:
 	case ERT_CLEANUP:
-	  /* Ok with the default C EH personality.  */
-	  break;
-
 	case ERT_CATCH:
-	  /* An empty type list is ok with the default C EH personality.  */
-	  if (i->u.eh_catch.type_list)
-	    return true;
-	  break;
-
 	case ERT_ALLOWED_EXCEPTIONS:
-	  /* An empty type list is ok with the default C EH personality.  */
-	  if (i->u.allowed.type_list)
-	    return true;
-	  break;
+	  return true;
 
 	case ERT_UNKNOWN:
 	  return true;
Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c.orig	2009-09-10 17:47:02.000000000 +0200
+++ gcc/tree-inline.c	2009-09-10 17:45:48.000000000 +0200
@@ -5000,12 +5000,10 @@ tree_can_inline_p (struct cgraph_edge *e
   callee = e->callee->decl;
 
   /* We cannot inline a function that uses a different EH personality
-     than the caller.  Restrict inlining functions with either no EH
-     personality or calls with matching personality in the caller
-     and callee for now, that will not require personality changes
-     in the caller.  Everything more advanced needs to be taken into
-     account during the inline plan computation.  */
-  if (DECL_FUNCTION_PERSONALITY (callee)
+     than the caller.  If we have functions without a specified EH
+     personality adjust them to reflect this possible inlining decision.  */
+  if (DECL_FUNCTION_PERSONALITY (caller)
+      && DECL_FUNCTION_PERSONALITY (callee)
       && (DECL_FUNCTION_PERSONALITY (caller)
 	  != DECL_FUNCTION_PERSONALITY (callee)))
     {
@@ -5013,6 +5011,19 @@ tree_can_inline_p (struct cgraph_edge *e
       gimple_call_set_cannot_inline (e->call_stmt, true);
       return false;
     }
+  else if (DECL_FUNCTION_PERSONALITY (caller)
+	   != DECL_FUNCTION_PERSONALITY (callee))
+    {
+      /* If the callee has callers we have to avoid mismatched inlining
+         into it.  */
+      if (DECL_FUNCTION_PERSONALITY (caller)
+	  && e->callee->callers)
+	DECL_FUNCTION_PERSONALITY (callee) = DECL_FUNCTION_PERSONALITY (caller);
+      /* If the callee has a personality avoid mismatched inlining into
+         the caller.  */
+      else if (DECL_FUNCTION_PERSONALITY (callee))
+	DECL_FUNCTION_PERSONALITY (caller) = DECL_FUNCTION_PERSONALITY (callee);
+    }
 
   /* Allow the backend to decide if inlining is ok.  */
   if (!targetm.target_option.can_inline_p (caller, callee))
Index: gcc/expr.c
===================================================================
--- gcc/expr.c.orig	2009-09-10 17:47:02.000000000 +0200
+++ gcc/expr.c	2009-09-10 17:40:14.000000000 +0200
@@ -10225,14 +10225,10 @@ get_personality_function (tree decl)
   tree personality = DECL_FUNCTION_PERSONALITY (decl);
   tree name;
 
-  if (!personality && !eh_personality_decl)
+  if (!personality
+      || !function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl)))
     return NULL;
 
-  if (!personality)
-    return init_one_libfunc (USING_SJLJ_EXCEPTIONS
-			     ? "__gcc_personality_sj0"
-			     : "__gcc_personality_v0");
-
   name = DECL_ASSEMBLER_NAME (personality);
 
   return init_one_libfunc (IDENTIFIER_POINTER (name));