On Fri, Jun 5, 2015 at 5:24 PM, Andrew MacLeod <amacl...@redhat.com> 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. > > 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?
Ok. Thanks, Richard. > Andrew
