Re: DECL_RTL vs. explicit make_decl_rtl calls

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

   From: Richard Henderson <rth@redhat.com>
   Date: Thu, 30 May 2002 11:46:36 -0700

   On Thu, May 30, 2002 at 04:02:06AM -0700, David S. Miller wrote:
   > Why do we ever perform explicit make_decl_rtl calls when
   > DECL_RTL will do that when necessary?
   
   One or two of them are to make sure that ENCODE_SECTION_INFO
   gets called.  Though there's no particular reason not to call
   that directly now that it's a target hook instead of a macro.

So I looked more deeply into this.  All the calls there now
need to happen because:

1) ENCODE_SECTION_INFO, in several backends, expect that it will be
   called on each function declaration.  It also wants to have the
   DECL_RTL() formed by the time it is called so Richard's idea
   of just calling ENCODE_SECTION_INFO directly won't work.

2) The other case, as Mark mentioned, involves asmspecs for
   hard register decl attributes.

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.

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.

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.