Re: DECL_RTL vs. explicit make_decl_rtl calls

["David S. Miller" <davem at redhat dot com>]

   From: law@redhat.com
   Date: Thu, 13 Jun 2002 08:50:59 -0600

   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.
   
Yes, even Sparc does this kind of stuff for function DECLs when using
certain code models on V9.

Looking at this problem further, what really matters is that the
most uptodate instance of the DECL gets looked at by
ENCODE_SECTION_INFO.  So if we saw an incomplete function
specification, then the final one, we'd have to be sure the
the final one is the last instance the backend sees.

With that in mind, all of the cases of invoking make_decl_rtl
explicitly that run with a NULL asmspec argument can really be changed
into:

	if (DECL_RTL_SET_P (decl))
	  make_decl_rtl (decl, NULL);

This would really get rid of all the truly spurious cases.

   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.
   
That's not the issue to me.  Imagine Jeff if we never generated ANY
throw-away RTL.  There is really some incredible stuff we could do at
such a point.

My goal is to one day be able to set a breakpoint ggc_alloc_rtx and
the backtrace from the first hit will be for real RTL generated for
real code in the file being compiled.

If we stop generating throw-away RTL, that means (perhaps requiring
some refcounting) we could do without garbage collection entirely.
YET keep the GC mechanism for RTL around to find bugs.

This may sound very daunting but I do not believe it to be an
impossible task.  My view is that garbage collection is just too damn
expensive for RTL allocation and it destroys locality.  I believe that
no amount of tweaking of GC is going to give enough of that
performance back.

GC is great for debugging allocation problems, it is in fact perfect
for looking into RTL usage issues.

So my grand view is that some day we have a situation that looks
something like this:

1) We have the page protection GC bits for TREE memory.  So we
   don't need to walk read-only TREE roots.

2) We eliminate wasteful and throw-away RTL allocations, we really
   keep track of what we are doing.

3) As a debugging mechanism we can use GC on RTL specifically to find
   new throw-away RTL instances that creep into the code and to find
   bugs.

I don't know how much throw-away memory occurs for TREE nodes, it is
an area for investigation for sure.

So for the people reading this and saying "no way, we have GC
specifically so we didn't have any RTL allocation debugging hassles
anymore, don't bring those problems back" keep in mind that we'll
still have GC there and we can have it enabled with some RTL specific
debugging features turned on by default in the devel sources.

Thanks for all of your data Jeff, it is very useful.