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]

[C++ PATCH] Don't inline calls in thunks (PR tree-optimization/34181)


On hppa2.0w-hp-hpux11.11 (reproduced with x86_64-linux ->
hppa2.0w-hp-hpux11.11_ cross) some thunks are not expanded using
targetm.asm_out.output_mi_thunk but TARGET_USE_LOCAL_THUNK_ALIAS_P
is not true either and so the jump to function is done as a normal
call.  If THUNK_TARGET wasn't needed yet, cgraph will abort though,
because there isn't anything preventing inlining THUNK_TARGET
into the thunk, but THUNK_TARGET might not be analyzed yet, which
tree_lowering_passes called from use_thunk expects to be already done.

To fix this, we can either make the CALL_EXPR CALL_CANNOT_INLINE_P
as done in the patch - aren't thunks meant to be just jumps to the
target functions?  Otherwise I wonder why would the mi_thunks be emitted
that way and similarly if we can TARGET_USE_LOCAL_THUNK_ALIAS_P;
or we could e.g. in ipa-inline handle CALL_FROM_THUNK_P
the same way as CALL_CANNOT_INLINE_P (but given that CALL_FROM_THUNK_P
is set in just one place in gcc, that solution would be slower),
or we could try hard to make inlining even into thunks possible
(not sure if that's possible).

Given that thunks that use a real call is just a fallback for targets
which can't do better in mi thunk output or TARGET_USE_LOCAL_THUNK_ALIAS_P,
I think disabling inlining in this case is ok.

Ok for trunk?

2007-11-27  Jakub Jelinek  <>

	PR tree-optimization/34181
	* method.c (use_thunk): Don't inline the call in the thunk.

--- gcc/cp/method.c.jj	2007-09-11 12:43:32.000000000 +0200
+++ gcc/cp/method.c	2007-11-27 11:52:13.000000000 +0100
@@ -481,6 +481,7 @@ use_thunk (tree thunk_fndecl, bool emit_
 	argarray[i] = a;
       t = build_call_a (alias, i, argarray);
       CALL_FROM_THUNK_P (t) = 1;
+      CALL_CANNOT_INLINE_P (t) = 1;
       if (VOID_TYPE_P (TREE_TYPE (t)))
 	finish_expr_stmt (t);


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