Flatten function.h

[Andrew MacLeod]

Im currently focusing on flattening middle/backend files which are
included from front-ends files so we can clean up the include interface
a bit.

This flattens function.h. It wasn't too bad, there were a few
prototypes and defines in expr.h and rtl.h that belong in function.h,
and a couple of other prototypes that belonged in other .h files. A
bunch of the gen*.c generated files actually use function.h.. so they
needed some tweaking.

I did an include file reduction on all the language/*.[ch] and core
*.[ch] files, but left the target files with the full complement of 7
includes that function.h use to have. Its probably easier when this is
all done to fully reduce the targets one at a time... there are so many
nooks and crannies I figured I'd bust something right now if i tried to
do all the targets as well :-)

Before the final commit, I will do an include reduction on
ada/gcc-interface/misc.c... my previous build didnt have Ada enabled, so
I missed the reduction there.

Bootstraps on x86_64-unknown-linux-gnu with no new test regressions (one
plugin test required adding an include). I've also run all the targets
in config-list.mk and the ones that built seem to build fine, but its
still running.. I'll verify before checking in.

for the record, this patch relocates the following include to where ever
function.h is included from. Any plugins which include function.h may
want to add these to the include list just before function.h

#include "hashtab.h"
#include "hash-set.h"
#include "vec.h"
#include "machmode.h"
#include "tm.h"
#include "hard-reg-set.h"
#include "input.h"

OK for trunk?

Andrew

[Joseph S. Myers]

I did an include file reduction on all the language/*.[ch] and core *.[ch]
files, but left the target files with the full complement of 7 includes that
function.h use to have. Its probably easier when this is all done to fully
reduce the targets one at a time... there are so many nooks and crannies I
figured I'd bust something right now if i tried to do all the targets as well
:-)

How did you determine what includes to remove? You appear to have removed
tm.h includes from various files that do in fact use target macros; maybe
they get it indirectly included by some other header, but I thought a
principle of this flattening was to avoid relying on such indirect
inclusions. Because of possible use of target macros in #ifdef
conditionals, "compiles with the include removed" is not a sufficient
condition for removing it.

cfgrtl.c
gimple-fold.c
mode-switching.c
tree-inline.c
vmsdbgout.c
fortran/f95-lang.c
fortran/trans-decl.c
objc/objc-act.c

[Andrew MacLeod]

Post by Joseph S. Myers

I did an include file reduction on all the language/*.[ch] and core *.[ch]
files, but left the target files with the full complement of 7 includes that
function.h use to have. Its probably easier when this is all done to fully
reduce the targets one at a time... there are so many nooks and crannies I
figured I'd bust something right now if i tried to do all the targets as well
:-)

How did you determine what includes to remove? You appear to have removed
tm.h includes from various files that do in fact use target macros; maybe
they get it indirectly included by some other header, but I thought a
principle of this flattening was to avoid relying on such indirect
inclusions. Because of possible use of target macros in #ifdef
conditionals, "compiles with the include removed" is not a sufficient
condition for removing it.
cfgrtl.c
gimple-fold.c
mode-switching.c
tree-inline.c
vmsdbgout.c
fortran/f95-lang.c
fortran/trans-decl.c
objc/objc-act.c

Many of those files do in fact get numerous include files from expr.h,
which are likely to get put back in when expr.h is flattened, but there
is a risk as you point out.

Perhaps I should proceed by simply moving the includes and removing any
duplicate includes, leaving the reduction for later date. There is less
chance of that causing issues. I did forget about the discussion last
year concerning target macros from the RTL end of things... My mind is
slowly going :-).



Andrew

[Andrew MacLeod]

Post by Andrew MacLeod

Post by Joseph S. Myers

I did an include file reduction on all the language/*.[ch] and core *.[ch]
files, but left the target files with the full complement of 7 includes that
function.h use to have. Its probably easier when this is all done to fully
reduce the targets one at a time... there are so many nooks and crannies I
figured I'd bust something right now if i tried to do all the targets as well
:-)

How did you determine what includes to remove? You appear to have removed
tm.h includes from various files that do in fact use target macros; maybe
they get it indirectly included by some other header, but I thought a
principle of this flattening was to avoid relying on such indirect
inclusions. Because of possible use of target macros in #ifdef
conditionals, "compiles with the include removed" is not a sufficient
condition for removing it.
cfgrtl.c
gimple-fold.c
mode-switching.c
tree-inline.c
vmsdbgout.c
fortran/f95-lang.c
fortran/trans-decl.c
objc/objc-act.c

Many of those files do in fact get numerous include files from expr.h,
which are likely to get put back in when expr.h is flattened, but
there is a risk as you point out.
Perhaps I should proceed by simply moving the includes and removing
any duplicate includes, leaving the reduction for later date. There
is less chance of that causing issues. I did forget about the
discussion last year concerning target macros from the RTL end of
things... My mind is slowly going :-).

OK, here's take 2.. I left all the include files except ones which were
duplicated as a result of the flattening. The first one was left, and
any subsequent #Includes of the files were removed. we'll address
"unneeded" includes separately and all at once.. perhaps with a newer
tool that has been taught about input and output dependencies

Bootstrapepd on x86_64-unknown-linux-gnu with no new regressions.
Currently config-list.mk is building, but Im not expecting any issues
there. assuming all is oK, ok to check in?

Andrew

PS.. the original commentary:

This flattens function.h. It wasn't too bad, there were a few
prototypes and defines in expr.h and rtl.h that belong in function.h,
and a couple of other prototypes that belonged in other .h files. A
bunch of the gen*.c generated files actually use function.h.. so they
needed some tweaking.

[Andrew MacLeod]

Ping... anyone want to take a look?

Andrew

Post by Andrew MacLeod

Post by Andrew MacLeod

Post by Joseph S. Myers

I did an include file reduction on all the language/*.[ch] and core *.[ch]
files, but left the target files with the full complement of 7 includes that
function.h use to have. Its probably easier when this is all done to fully
reduce the targets one at a time... there are so many nooks and crannies I
figured I'd bust something right now if i tried to do all the targets as well
:-)

How did you determine what includes to remove? You appear to have removed
tm.h includes from various files that do in fact use target macros; maybe
they get it indirectly included by some other header, but I thought a
principle of this flattening was to avoid relying on such indirect
inclusions. Because of possible use of target macros in #ifdef
conditionals, "compiles with the include removed" is not a sufficient
condition for removing it.
cfgrtl.c
gimple-fold.c
mode-switching.c
tree-inline.c
vmsdbgout.c
fortran/f95-lang.c
fortran/trans-decl.c
objc/objc-act.c

Many of those files do in fact get numerous include files from
expr.h, which are likely to get put back in when expr.h is
flattened, but there is a risk as you point out.
Perhaps I should proceed by simply moving the includes and removing
any duplicate includes, leaving the reduction for later date. There
is less chance of that causing issues. I did forget about the
discussion last year concerning target macros from the RTL end of
things... My mind is slowly going :-).

OK, here's take 2.. I left all the include files except ones which
were duplicated as a result of the flattening. The first one was left,
and any subsequent #Includes of the files were removed. we'll address
"unneeded" includes separately and all at once.. perhaps with a newer
tool that has been taught about input and output dependencies
Bootstrapepd on x86_64-unknown-linux-gnu with no new regressions.
Currently config-list.mk is building, but Im not expecting any issues
there. assuming all is oK, ok to check in?
Andrew
This flattens function.h. It wasn't too bad, there were a few
prototypes and defines in expr.h and rtl.h that belong in function.h,
and a couple of other prototypes that belonged in other .h files. A
bunch of the gen*.c generated files actually use function.h.. so they
needed some tweaking.