From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3639 invoked by alias); 8 Jun 2015 13:48:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 1663 invoked by uid 89); 8 Jun 2015 13:48:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f178.google.com Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com) (209.85.214.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 08 Jun 2015 13:48:08 +0000 Received: by obbqz1 with SMTP id qz1so80468116obb.3 for ; Mon, 08 Jun 2015 06:48:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.102.2 with SMTP id fk2mr14674458obb.35.1433771286058; Mon, 08 Jun 2015 06:48:06 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Mon, 8 Jun 2015 06:48:06 -0700 (PDT) In-Reply-To: <5571BF13.2070103@redhat.com> References: <5571BF13.2070103@redhat.com> Date: Mon, 08 Jun 2015 13:57:00 -0000 Message-ID: Subject: Re: [patch] Adjust hash-table.h and it's pre-requisite includes. From: Richard Biener To: Andrew MacLeod Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00571.txt.bz2 On Fri, Jun 5, 2015 at 5: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. > > 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 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