[RFC] Initial header file re-work proposal

[RFC] Initial header file re-work proposal

[Andrew MacLeod]

Now that I have a good chunk of the major crap dependencies removed, I'd 
like to consolidate a few things, and reintroduce certain includes back 
to a few header files.

First, the methodology I used.  I completely flattened a branch (no 
header file includes any other header file), and focused on the files 
that make up libbackend.a,.  I took out a few out of the list for 
various reasons, and was left with 321 source files.

My new include removal tools analyzes #if expressions in (header and 
source)  and wont remove any header file which provides a macro which is 
used  in a conditional compilation.
If a source file compiles without the header successfully, and has no 
conditional dependencies on that header, it then it spawns off a set of 
83 core target builds of that source file to make sure it also compiles 
on a wide selection of targets.  There are 203 targets in config-list, I 
reduced it to 83 by eliminating various OS combinations leaving a single 
target for each kind of hardware . (Before checking anything in, I 
always run it through all the targets)

I ran the include removal tool on all 321 source files, trying to remove 
every header file once at  a time. This left me with only required 
headers in each source file.  I then ran another tool which analyzed the 
output of each of the failed removals across all 321 files, and built up 
a dependency database which showed which include files failed because 
they needed other include files, and more importantly, WHY it was needed.

I used the output from that to develop the patches over the past few 
weeks to remove some of the undesirable dependencies between files.

With those dependencies removed, I used a couple of more tools to 
analyze what header files appear in common groups, and built up sets of 
headers that are normally needed together.

So before creating patches for this, I figured I'd first get agreement 
that it makes sense.


-  symtab,h is a hard-requirement for tree-core.h to compile so simply 
include it

- hard-reg-set.h should be included in rtl.h.  rtl.h does different 
things when hard-reg-set.h hasn't been included, so it always has to be 
included before rtl.h. In many ways this is a dependency because of 
that.  rtl.h is included in some generator files, and I think that adds 
some confusion to the situation, but it turns out that whenever rtl.h is 
being included, hard-reg-set.h can also be included harmlessly.. even 
from a scratch build in those generators since they require tm.h and 
that is a prerequisite for hard-reg-set.h..  They are *always* used 
together so just include it.

- df.h has hard dependencies on :  regset.h, timevar.h, and 
alloc-pool.h, and these all tend to be used together, so include them 
from df.h (and nothing else)

- cfg.h has a hard dependency on dominance.h, so include that directly.

- I had planned to introduce a tree-group and rtl-group header which 
files could include when they needed trees or rtl.   It turns out that:
235 files include tree.h,
17 more include tree-core.h only
41 more include rtl.h only (no tree of any kind)
when I looked at the set of files that were included with each of those 
groups, it was a very common set of files.  So instead of 2 different 
groups, I propose that I create a new header file such as "backend.h" 
which will include all the files that are used the vast majority of 
them.   Source files would include this file right after coretypes.h, 
and then include "tree.h", "rtl.h", and/or "gimple.h" .

so a source file might well start:
#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "backend.h"
#include "tree.h"
#include "gimple.h"
<...>


This should simplify things dramatically, and not add any extra includes 
into tree.h or rtl.h when they are included by other non-libbackend.a files.
backend.h would initially consist of:
#include "tm.h"
#include "function.h"
#include "bitmap.h"
#include "sbitmap.h"
#include "predict.h"
#include "basic-block.h"
#include "cfg.h"

  - gimple.h has hard dependencies on tree-ssa-alias.h, gimple-expr.h, 
and fold-const.h.   Include those directly. tree-ssa-alias.h should 
probably be renamed, but we can consider a mass renaming of tree-ssa-* 
stuff later..

- There are also some ssa related files which are quite frequently used 
together.  I was going to suggest introducing ssa.h and include such 
headers there,  but I noticed that tree-ssa-operands.h is the true 
backbone... none of the ssa related things can operate without it, and 
it isn't needed unless ssa is being operated on.   So for an ssa header, 
Id propose renaming tree-ssa-operands.[ch] to just ssa.[ch] and adding 
the following includes:
#include "gimple-ssa.h"
#include "tree-ssanames.h"
#include "tree-phinodes.h"
#include "stringpool.h"
#include "ssa-iterators"

  These tend to be the primary ssa headers which are needed in practice. 
   If that isn't desirable, then Id introduce ssa.h.

Once these groups are created, and source files modified to use them and 
remove the duplicated includes from their list,  I'd run the include 
reduction tool across the board on all the libbackend files,  then each 
of the front ends and targets.

Then we can re-assess what things look like. I expect there will be some 
tweaking to these groups, and we can see what other groups might make 
sense.. I can also see if there is something that would be helpful for 
the various frontends since I haven't really analyzed the stuff outside 
libbackend yet.  I'm trying to get the backend house in order first so 
there isn't much interference from false dependencies and we can see 
what they really need. :-)

What do you think of these groupings?  I plan to start creating patches 
based on this.

Andrew