This is the mail archive of the
mailing list for the GCC project.
Re: RFC - Next refactoring steps
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, Diego Novillo <dnovillo at google dot com>, Mike Stump <mikestump at comcast dot net>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 6 Sep 2013 08:50:46 +0200
- Subject: Re: RFC - Next refactoring steps
- Authentication-results: sourceware.org; auth=none
- References: <20130809223645 dot GA22559 at google dot com> <48A1A20B-1DF2-45A5-9CB6-13CDC6A89A4F at comcast dot net> <cf6d07ba-b8bc-43c2-9f84-e7709ed7730e at email dot android dot com> <5214F775 dot 60702 at redhat dot com> <B962A2B6-233D-4B65-B4BF-CE1B20B0154B at comcast dot net> <52161471 dot 6040408 at redhat dot com> <CAD_=9DTQhKGQHn6KgGJg9bQN9_Ft5DaE3fKJr8OuaALhjQSy+g at mail dot gmail dot com> <CAFiYyc3Tc24A5LExuvOKH_poXqYyJ_GUE8-CbxK1cMnY2VPmUQ at mail dot gmail dot com> <52287FD3 dot 4040204 at redhat dot com> <CAFiYyc0yGMVohSBVdpboTMeFw229DW3ZFbg_rUqSSWUvu0zFqg at mail dot gmail dot com> <5228A7A7 dot 9070606 at redhat dot com> <CABu31nOMLWyk+T4LBnwPhYjrPVMtCHAtP2Gdqv1g40vgOfLraQ at mail dot gmail dot com>
On Thu, Sep 5, 2013 at 11:53 PM, Steven Bosscher <email@example.com> wrote:
> On Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod <firstname.lastname@example.org> wrote:
>> ok, so to dwell on header file cleanup. When creating new header files for
>> say, tree-ssa-ter.h, what other include files should we make assumptions
>> have already been included... or should we make none?
>> For instance, the header files tree-ssa-ter.h would require system.h,
>> bitmap.h, tree-ssa-live.h, and gimple.h (soon to be gimple-core.h I hope :-)
>> to parse the prototypes
> Why bitmap.h? bitmap is in coretypes.h.
> Anyway, a little more side-stepping: on my wishlist is making the
> various data types (sbitmap, bitmap, sparseset, etc.) independent of
> gcc headers as much as possible, and having a single header, gccadt.h
> say, that provides most/all generic data structures (e.g. also
> including hash tables).
Yeah, and we could move all the files into a lib/ subdirectory (well, or
make them part of libiberty).
>> Of course, trimming the .c file include list with some intelligence would
>> help minimize this, but not completely eliminate it.
> As you may have noticed, I tried trimming the #include lists in many
> .c files last year. It's a hard but worthwhile job: You find some
> headers have to be included before others, or some headers are used by
> some .c file but they don't #include it. Instead they receive it
> through an #include in some .h file but nothing defined directly, i.e.
> not via #include, is used in the .c file.
>> thats just an example, I don't think we need a tree-ssa-ter.h. There are
>> only 3 exported functions. 2 are used exclusively in tree-outof-ssa.c and
>> one is used in expr.c (a reuse of the is_replaceable_p function.)
>> The 2 that are exclusive to tree-out-ssa.c could simple have the prototypes
>> in tree-outof-ssa.c, That seems like the best thing to do for single
> Not really. It's a single client now, but if it's an exported
> interface of some kind, then why should its use stay limited to a
> single client?
> Either some function is exported and therefore should have a prototype
> in a .h file, or something is local to a file and no prototype is
> necessary (in most cases anyway).
>> The other function could be moved from tree-ssa-ter.c to expr.c, and the
>> prototype exported in expr.h and used in tree-ssa-ter.c
> Makes sense.