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]

[RFC] Fix for PR58201


Hi,
this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for functions w/o
bodies I did not really anticipate.

Here removal of the arguments changes mangling algorithm if
set_decl_assembler_name is invoked late.  This is something I wanted to get rid
of for a long time:  we already compute assembler names for every symbol that
lands symbol table after the early cleanups for every unit that is LTOed and
every unit containing any alias directive.  I think it will make things
smoother if we computed it always early: other persistent source of problems
are same body aliases that are created as a side effect of langhook of
set_decl_assembler_name and that may happen at a time IPA code does not really
expect new functions/variables to appear.

So independently of DECL_ARGUMENTS/DECL_RESULT issues, I would like to propose the
following patch that triggers unconditional computation of DECL_ASSEMBLER_NAME and the
real symbol table construction.  I already benchmarked it few months ago and the
erformance implications seems in wash.

Just to keep things linked, the other two fallouts are
 1) problem with thunks needing DECL_ARGUMENTS when they are output in gimple way
    but these are not streamed, handled by http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00057.html
 2) problem with variable sized arguments and return values
    "fixed" by http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00078.html
    (the fix restored old behaviour, but I do not think it fixes the whole issue
    as discussed in the thread and provided with another testcases that ICEs the
    compiler independently of my changes).

I would like to basically ask if it seems to make sense to go this route and
try to get rid of those declarations.

For LTO it is really nice optimization - instead of streaming 4 decls at
average for a function (function-decl, result-decl and parm-decls), we need
just one. This change was originally motivated by memory analysis of firefox
WPA build where PARM_DECL was the most common type of tree just after
TREE_LIST.  I also think it makes sense from backend point of view to consider
these part of the function body representation, just as DECL_STRUCT_FUNCTOIN
and DECL_INITIAL is.

Even in non-LTO we save a lot of decls for all the external declarations that
are kept in memory.

I would be willing to try to analyze/fix the issues if they appear and I tried
quite curefuly to examine the existing code dealing with arguments. There
are obviously interesting scenarios, like this mangling issue, I missed.

If this does not seem to make sense, I will prepare patch to revert the changes.
If it does, I will commit those fixes and hope things will stabilize quickly.

Honza

	* cgraphunit.c (analyze_functions): Populate assembler names once done
	with early unreachable function removal.

Index: cgraphunit.c
===================================================================
--- cgraphunit.c	(revision 202199)
+++ cgraphunit.c	(working copy)
@@ -1074,6 +1086,7 @@
   bitmap_obstack_release (NULL);
   pointer_set_destroy (reachable_call_targets);
   ggc_collect ();
+  symtab_initialize_asm_name_hash ();
 }
 
 /* Translate the ugly representation of aliases as alias pairs into nice


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