Re: [patch] consolidate some includes into coretypes.h

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Jun 1, 2015 at 11:02 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> I've begun looking at cleaning up the include files. Before removing
> unnecessary includes, I'd like to get a few other cleanups out of the way to
> simplify the dependency web. This is the first.
>
> There are some interrelated numerical definition headers (double-int.h,
> fixed-value.h, real.h and wide-int.h) .  Virtually every gcc source file
> ends up including them indirectly one or more times.  They also end up
> including signop.h and machmode.h as prerequisites as well.
>
> first,
>
> #include "machmode.h"
> #include "signop.h"
> #include "wide-int.h"
> #include "double-int.h"
>
> any source file  which includes tree.h, gimple.h *or* rtl.h will require all
> of these to compile.  That is basically the entire compiler.
>
> then there are:
>
> #include "real.h"
> #include "fixed-value.h"     /* require real.h to compile */
>
> rtl.h has a hard dependency on these 2 files to compile, and although tree.h
> still parses and compiles when they are not included, it does provide some
> macros which access tree fields which return a FIXED_VALUE.   Any file which
> includes tree.h could therefore require real.h and fixed-value.h if they use
> the results of those macros.
>
> That said, I tried flattening these includes throughout the compiler to see
> exactly which other source files really need real.h and fixed-value.h.  I
> changbed it such that those 2 files were included by rtl.h, realmpfr.h, and
> dfp.h which have hard requirements.  I found about 37 of the remaining
> source files required real.h and about 16 required fixed-value.h
>
> Personally given those numbers and since tree.h exposes potential uses of
> FIXED_VALUE, the simple and cleanest thing to do is just add all 6 of these
> includes to the basic pre-requisites for source files.
>
> Currently, all source files start with
> #include "config.h"
> #include "system.h"
> #include "coretypes.h"
>
> The first include can be different for generator (bconfig.h) and target
> (tconfig.h) files,  so with a small tweak to coretypes.h to include these 6
> header files when config.h has been included (by checking if GCC_CONFIG_H is
> defined),  everything pretty much magically works.  I think it makes sense
> to put them there since they are core types and is already included
> everywhere its needed. If that is not satisfactory, I could create a new
> include file which comes after coretypes when appropriate...
>
> The only exception is the cases where rtl.h is included by some generator
> file. These generator files are used late enough in the build  that
> insn-modes.h exists and can safely include all these files.  I added a
> condition to rtl.h to include these files when GENERATOR_FILE is defined
> since they wouldn't have been included by coretypes.h normally.
>
> With that change I can remove *all* other #includes of these 6 files, and
> simplify the initial part of the include web quite nicely.  I also used the
> opportunity to remove coretypes.h from a couple of includes that no longer
> need to include it.
>
> there are 2 patches. The first is short and has the interesting changes, the
> second is purely automated and removes all the extraneous #includes of these
> files which are now all encapsulated in coretypes.h.
>
> Bootstraps from scratch on x86_64-unknown-linux-gnu with no new test
> regressions.  I also built it on all the config-list.mk targets with no
> additional compilation errors.
>
> OK for trunk?

Generally the idea is sound (amend coretypes.h), but I don't like the
GCC_CONFIG_H guard, why does !GENERATOR_FILE not work?

Furthermore I don't like the special-casing in rtl.h, instead have
coretypes.h contain sth like

#ifdef GENERATOR_FILE
... rtl.h special-case
#else
... GCC_CONFIG_H stuff
#endif

Thanks,
Richard.

> Andrew
>
> -  I do have a functioning patch which moves real.h and fixed-value.h to the
> required source files, I just dont like it as well so propose this one
> first.
>