On 06/05/2015 05:24 PM, Andrew MacLeod wrote:
> There is a horrible morass of include dependencies between hash-map.h,
> mem-stats.h and hash-table.h. There are even includes in both directions
> (mem-stats.h and hash-map.h include each other, as do hash-map.h and
> hash-table.h.. blech). Some of those files need parts of the other file to
> compile, and those whole mess is quite awful. They also manage to include
> vec.h into their little party 3 times as well, and it also has some icky
> #ifdefs.
>
> So I spent some time sorting out the situation, and reduced it down to a
> straight dependency list, rooted by hash-table.h. There are no double
> direction includes, and no header is included more than once. Once sorted
> out, I moved the root of this tree into coretypes.h since pretty much every
> file requires everything in the dependency chain. This chain consists of
> statistics.h, ggc.h, vec.h, hashtab.h, inchash.h, mem-stats-traits.h,
> hash-map-traits.h, mem-stats.h, hash-map.h and hash-table.h.
Hello Andrew.
Thank you for solving issue related to the aforementioned cycle. Few weeks ago,
I implemented memory statistics support for hash-{set|table|map}, which
internally uses a hash-map and that's the reason why it was a bit awful.
Anyway, nice work!
Martin
>
> With hash-table.h at the root of the dependency list, I wondered how many
> files actually need just that. So I flattened a source tree such that
> coretypes.h included the other required include files, but each .c file
> included hash-table.h. Then I tried removing the includes. It turned out
> that virtually every file needs hash-table.h. Part of that is due to how
> tightly integrated with mem-stats.h it is (they still need each other), and
> that is used throughout the compiler. So I think it makes sense to put that
> in coretypes.h.
>
> I also noticed that hash-set.h is included in a lot of places as well.
> Wondering how much it was actually needed, I preformed the same flattening
> exercise and found that only about 10% of the files in gcc core didn't need
> it to compile... the rest all needed it due to hash_set<sometype> being in a
> prototype parameter list or in a structure declared in a commonly used header
> file (function.h, gimple-walk.h, tree-core.h, tree.h,...) . It would be a
> lot of work to remove this dependency (if its even possible), so I added
> hash-set.h to coretypes.h as well. rtl.h needed hash-table.h added to the
> GENERATOR list, but not hash-set.. I guess the generators don't use it much
> :-)
>
> The only other thing of note is the change to vec.h. It had an ugly set of
> checks to see whether it was being used in a generator file, and if not
> whether GC was available, then included it if it wasn't or provided 3
> prototypes if it wasn't suppose to be included. These allows it to compile
> when GC isn't available (those routines referencing the GC functions would
> never be referred to when GC isnt available). With my other changes, most
> of those checks weren't necessary. I also figured it was best to simply
> include those 3 prototypes for ggc_free, ggc_round_alloc_size, and
> ggc_realloc all the time. When there isn't ggc.h, things remain as they are
> now. If there is a ggc.h included, it will provide static confirmation that
> those prototypes are up-to-date and in sync with how ggc.h defines them.
>
> The first patch contains all of those changes. The second one is fully
> automated and removes all these headers from every other .c and .h file in
> the compiler. This also included changes to many of the gen*.c routines. I
> adjusted the #include list for all the *generated* .c files to also be up to
> date with this patchset as well at the previous one which moved wide-int and
> friends into coretypes.h
>
> This bootstraps with all languages enabled on x86_64-unknown-linux-gnu with
> no new regressions. It also causes no failures for all the targets in
> config-list.mk.
>
> OK for trunk?
>
> Andrew
