This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch 1/8] Remove gimple-low.h from the tree-ssa.h include list.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 21 Oct 2013 14:16:17 +0200
- Subject: Re: [patch 1/8] Remove gimple-low.h from the tree-ssa.h include list.
- Authentication-results: sourceware.org; auth=none
- References: <5260856C dot 7070008 at redhat dot com> <52613980 dot 9050507 at redhat dot com> <52615D6E dot 3030404 at redhat dot com> <5261859D dot 6000806 at redhat dot com>
On Fri, Oct 18, 2013 at 9:01 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 10/18/2013 12:10 PM, Jeff Law wrote:
>>
>> On 10/18/13 07:37, Andrew MacLeod wrote:
>>>
>>>
>>> gimple_check_call_matching_types() was being called from 3 or 4
>>> different files,and seemed more appropriate as a cgraph routine (which
>>> called it 3 times). So I moved that and its helper to cgraph.c.
>>>
>>> After that, I only needed to update 4 .c files to directly include
>>> gimple-low.h
>>>
>>> bootstraps on x86_64-unknown-linux-gnu with no new regressions. OK?
>>
>> I'm less sure about this one. I don't see that it clearly belongs in
>> either location. I could easily see it moving out of cgraph.c at some
>> point.
>>
>> If it furthers your cleanup efforts at this time, that's fine. Just be
>> aware that, at least IMHO, this routine doesn't fit clearly into either
>> location and I wouldn't be surprised if we have to come back to it at some
>> point.
>>
> possibly, there didn't seem to be a tree call file for call helpers, so I
> went with locality :-) I will happily move it to a more appropriate place
> as a follow up. cgraph.h is already a collector for the exports for a half
> dozen .c file. It needs the same treatment tree-flow got.
I think that we should remove all indirect includes again at some point
to get a clearer picture of what is used where. After all prototypes are
in the appropriate header files, of course...
So the less indirect includes the better (for now).
Richard.
> Andrew