RFC/RFA: basic-improvements: split config.h and tm.h

[Zack Weinberg <zack at codesourcery dot com>]

About eight months ago[1] I attempted to split the target
configuration headers out of config.h.  Only about half of GCC's
source files actually have intentional dependencies on the target
configuration, but currently, if you change config/arch/arch.h you get
to recompile everything.  When I last tried to rectify this, it turned
out that there were a bunch of hidden dependencies in the broadly-used
header files, that made the change impractical.  I believe that these
have now been rooted out, and I would like to make another attempt.

I would like to proceed in an unusual fashion: I'm going to describe
in detail what I propose to do in this message, and I ask for
pre-approval for the actual patches based on this description.  I want
to do it this way because it does not make much sense to apply part of
the change, but for testing purposes it's going to be helpful to break
it up into steps, so I want an okay on the whole thing before I start.
Also, one of the steps will make a one-line change to every last .c
file in the source tree, which provokes worst-case performance from
CVS's network protocol, so carrying it around for even the typical
couple of days it takes for patch review will be extremely painful.
For the same reasons, I intend to test each step as I go, but only
commit the final result.

Step one of the change is much as it was in my previous submission:
create a config.h-alike called "tm.h" that includes all the target
description headers.  However, unlike last time, all three of
config.h, hconfig.h, and tconfig.h will at this stage #include "tm.h".

Step two creates a file named "coretypes.h" which at this stage
contains solely the forward declarations of tree, rtx, and rtvec that
are presently incorporated into *config.h.  config.h and hconfig.h
include that header between the xm headers and "tm.h"; tconfig.h gets
instead fake declarations of the form

struct _dont_use_foo_here_;
#define foo struct _dont_use_foo_here_ *

as was done in my previous submission.  (These definitions cause no
trouble if used in function prototypes or variable declarations, but
if the types are actually _used_ -- which they should not be, in code
that includes tconfig.h -- they will provoke errors.)

Step three is a mechanical change that touches every last .c file,
inserting #includes of coretypes.h and tm.h after system.h.  Unlike
the last time, I am not going to try to winnow it down any at this
stage.  The Makefiles change to match, and the inclusions are removed
from config.h and hconfig.h.

Step four may seem a bit counterproductive: I slurp the declaration of
enum machine_mode out of machmode.h into coretypes.h.  This makes a
whole bunch of header-header interdependencies go away; the cost is
that changes to machmode.def or @extra_modes_file@ do force
recompilation of everything, but I think we can live with that -- we
don't change the set of modes often.

There is a break point here; I propose to reach it and then commit all
the changes so far.  That will not remove any edges from any
dependency graphs, only hoist them all out into the open where they
can be got at.

Step five is to go through the compiler file by file and remove
inclusions of tm.h when they are unnecessary.  This is parallelizable;
if people get inspired and decide to help out, they can do so at this
stage -- which is a major reason why I suggest committing before this
step.  This step does require very careful testing; some files have
dependencies on tm.h that manifest only on some targets.  It is likely
that related structural cleanups can happen at this stage: there may
well be files that have dependencies on tm.h but don't need them.  For
instance, rtl.h currently imposes a dependency on tm.h because it
inappropriately contains several default definitions for target
macros; these can be moved to defaults.h instead.

So.  Thoughts?  Flames?  Approvals?

zw

[1] http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00059.html