Re: [patch] Adjust hash-table.h and it's pre-requisite includes.

["Martin Liška" <mliska@suse.cz>]

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