Re: DECL_RTL vs. explicit make_decl_rtl calls

[law at redhat dot com]

 In message <20020613.025639.16264375.davem@redhat.com>, "David S. Miller" 
writes:
 > Now, thinking more about #1 it really shouldn't matter.  If we were to
 > omit these explicit make_decl_rtl calls we would end up calling
 > ENCODE_SECTION_INFO if we ever try to get at the DECL_RTL.
 > This assumes the ENCODE_SECTION_INFO is not changing the DECL tree
 > itself in any way, is it allowed to do this?  If it can, we can't
 > get rid of the make_decl_rtl() calls with NULL asmspec argument.
On the PA ENCODE_SECTION_INFO extracts the RTL from the tree structure,
then modifies the RTL (sets SYMBOL_REF_FLAG and may change the string
inside a SYMBOL_REF).  I doubt that counts since we're not modifying the
DECL, but instead the RTL that is referenced by the DECL.

 > There is also a bunch of stuff in make_decl_rtl dealing with mode
 > changes if we've got the DECL_RTL already.  Does this really happen?
 > If so, this would also invalidate the optimization of getting rid of
 > make_decl_rtl calls with NULL asmspec argument.
No idea.


 > I keep coming back to this because it is a source of a lot of throw-
 > away RTL as header files are being parsed.  Every function declaration
 > generates a bunch of RTL even if that function is never referenced in
 > the sources ever again.
Well, from looking at my profiling data, make_decl_rtl only get called
on the order of 57 thousand times.  Those calls result in about 100 thousand
hunks of RTL being generated.    To put that in perspective, that is less
than .2% of the total number of calls to allocate garbage collected memory.

If you want to make a significant dent in the amount of throw away
RTL we generate, look at how we use copy_rtx in cse.c.

rtx_alloc accounts for 15% of all allocations of garbage collected memory
(it's #1).

More than 50% of the calls to rtx_alloc occur from copy_rtx.

More than 50% of the calls to copy_rtx occur from cse_insn directly, plus
about another 25% from find_best_addr.


cse_insn makes a copy of src_eqv_here, src_related or elt->exp each
iteration of the while loop which performs replacements -- which is
performed on each insn in each block (and remember blocks can be 
processed more than once).  I suspect most of these are throw-aways,
but I haven't looked deeply at them yet.

It also makes a copy of src_const when it creates a REG_EQUAL note,
but I suspect most of the copy_rtx calls are in that replacement while
loop.


The #2 abuser of garbage collected memory is make_node, also with 15%
of the calls to allocate garbage collected memory.  I haven't investigated
this call chain at all.

The #3 abuser of garbage collected memory is gen_rtx_fmt_ee, again with
15% of the calls to allocate garbage collected memory.  The major abuses
here are alloc_EXPR_LIST, simplify_plus_minus and emit_move_sequence (PA 
backend).
There may be some fluff here, but I haven't looked closely.



Note these are based on compiling for the PA.  Other targets may be different
(though a spot-check of the x86 showed the same 3 abuses of ggc_alloc, but
with rtx_alloc and make_node reversed in importance).


jeff