On 07/22/2015 06:50 PM, Andrew MacLeod wrote:
This is the result of running include reduction on all the files which
make up libbackend.a, as well as most of the language files found in
subdirectories lto, c ,cp, java, go, fortran, jit, ada. well, some of
ada. :-)
I looked at the output and hand tweaked a few things... removing
comments that no longer made sense and stuff like that.
The reduction tool was run across all the targets to pick up macros that
might be defined. An Include file was not removed if it defined a macro
which was used in a conditional expression (ie #if) either in the source
file, or in other includes files which were determined to be required.
During removal, the header was removed on the host machine, and if
compilation was successful, the tool proceeded to try it on all
targets. I did a dry run on all 201 functioning targets, and the
results from 1.7 million lines of log file showed that full coverage can
be attained with 13 targets:
aarch64-linux-gnu arm-netbsdelf avr-rtems c6x-elf epiphany-elf
hppa2.0-hpux10.1 i686-mingw32crt i686-pc-msdosdjgpp mipsel-elf
powerpc-eabisimaltivec rs6000-ibm-aix5.1.0 sh-superh-elf sparc64-elf
spu-elf
The final run was on the coverage targets, and ran much much faster.
I then ran it through an ordering tool, (which I will eventually put in
contrib). This tool looks at include files, and puts them in a
"standard" order, and removes duplicates that have already been
included.. even if it is indirectly via another file. ie, it will
remove obstack.h from the list if bitmap.h has been included for instance.
removing duplicates was a very delicate balancing act when trying to
aggregate them with other includes,
ie
#include "option.h"
<...>
#include "target.h"
Since target.h includes tm.h (which includes options.h). we don't need
to include options.h BUt there may be header files between the two that
require something in options.h, so target.h needs to be moved up to the
options.h location. There are often secondary effects which affect
other files, and it turned out to be a frustrating juggling act. So I
wrote the tool to take care of it. The standard "grouping" order of
includes turns out to look like :
"system.h",
"coretypes.h",
"backend.h",
"target.h",
"rtl.h",
"tree.h",
"fortran/gfortran.h",
"c-family/c-common.h",
"c/c-tree.h",
"cp/cp-tree.h",
"gimple.h",
"df.h",
"tm_p.h",
"gimple-iterators.h",
"ssa.h",
"expmed.h",
"optabs.h",
"recog.h",
"gimple-streamer.h"
This order resolves any issues. The tool also looks at all the files
included by these and avoids including them a second time. Note that it
only puts header files into this order which are in the source file. so
if backend.h isnt in the file, and function.h is, function.h will occur
where backend.h would be. Any headers included by backend.h will occur
in that relative position, and in the order they are included by backend,.h
I will eventually put all these tools into a directory in contrib. It
simple enough to run it this ordering on any source file.
This patch is my best effort at a correct include reduction. I
bootstrapped it on both x86_64-unknown-linux-gnu and
powerpc64le-unknown-linux-gnu, with no regressions on either host. It
builds all 201 config-list.mk targets which currently build. Im not
aware of any bugs in the tools and my testing seems to show they work
OK. , and everything seems sane. Some files look dramatically better :-)
ok for trunk?
I will make tweaks to the tool in order to do the config directories
next, and a few remaining files that have not been reduced yet.
Given the mechanical nature and size, I just did spot checks which
looked fine.
OK for the trunk.
jeff
