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