This is the mail archive of the
mailing list for the GCC project.
[RFC] Fix for PR58201
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: gcc-patches at gcc dot gnu dot org, jason at redhat dot com, rguenther at suse dot de
- Date: Wed, 4 Sep 2013 18:04:09 +0200
- Subject: [RFC] Fix for PR58201
- Authentication-results: sourceware.org; auth=none
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.
* cgraphunit.c (analyze_functions): Populate assembler names once done
with early unreachable function removal.
--- cgraphunit.c (revision 202199)
+++ cgraphunit.c (working copy)
@@ -1074,6 +1086,7 @@
+ symtab_initialize_asm_name_hash ();
/* Translate the ugly representation of aliases as alias pairs into nice