RFA: current_function_funcdef_no vs. target_reinit

Richard Sandiford rdsandiford@googlemail.com
Thu Jun 26 21:16:00 GMT 2008


I think we should make:

  ...switch to a new subtarget...
  target_reinit ();
  ...switch back to the old subtarget...
  target_reinit ();

a no-op sequence as far as possible.  For example, PCH files should
only be sensitive to the target in use for each given function;
they should not be sensitive the _number_ of target_reinit calls.

This patch fixes one case where the sequence isn't a no-op.
backend_init_target has the following code:

  /* The following initialization functions need to generate rtl, so
     provide a dummy function context for them.  */
  init_dummy_function_start ();

And this dummy function gets a unique function definition number,
meaning that the call leaves a trace in function.c:funcdef_no.

A definition number of 0 should be fine for the dummy function,
so this patch only allocates a unique number for non-null decls.

Tested on mipsisa64-elfoabi and x86_64-linux-gnu.  It fixes some
PCH regressions caused by another patch that I'm about to post.
OK to install?

Richard


gcc/
	* function.c (allocate_struct_function): Only allocate a unique
	funcdef_no if the decl is nonzero.

Index: gcc/function.c
===================================================================
--- gcc/function.c	2008-06-24 17:15:41.000000000 +0100
+++ gcc/function.c	2008-06-24 17:16:05.000000000 +0100
@@ -3843,8 +3843,6 @@ allocate_struct_function (tree fndecl, b
 
   cfun = ggc_alloc_cleared (sizeof (struct function));
 
-  current_function_funcdef_no = get_next_funcdef_no ();
-
   cfun->function_frequency = FUNCTION_FREQUENCY_NORMAL;
 
   init_eh_for_function ();
@@ -3860,6 +3858,7 @@ allocate_struct_function (tree fndecl, b
     {
       DECL_STRUCT_FUNCTION (fndecl) = cfun;
       cfun->decl = fndecl;
+      current_function_funcdef_no = get_next_funcdef_no ();
 
       result = DECL_RESULT (fndecl);
       if (!abstract_p && aggregate_value_p (result, fndecl))



More information about the Gcc-patches mailing list