This is the mail archive of the
mailing list for the GCC project.
Re: RFC - Next refactoring steps
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Richard Biener <richard dot guenther at gmail 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: Thu, 05 Sep 2013 18:22:49 -0400
- 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 09/05/2013 05:53 PM, Steven Bosscher wrote:
On Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod <email@example.com> 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.
well, only because a function prototype used the bitmap type... I
suppose you could include coretypes.h, but then you get even more stuff
included. I was making the list the "minimal" required to compile the
Or are you suggesting that coretypes.h is a file we can assume is
available? that seems like a bit of a slippery slope, but we could pick
a few. I prefer it be explicit myself.
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
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).
Its exported only because the original file was split for modularity
reasons., otherwise tree-outof-ssa.c would be much larger. If we had
such a think as a "module clump", it would only be visible inside that
If we go down the path of "its external so it it should be in a header
file", then we will probably need to have pass-xyz.h header files.. ie,
I would be creating a tree-ssa-ter.h file to put 2 externals in that are
only used by tree-outof-ssa.c. a small sortof useless header file we
don't actually need. it is cleaner than in putting it in tree-flow.h
of course :-)
IIf I were to create a tree-ssa-ter.h file, then Id just leave the
prototype in tree-ssa-ter.h :-)
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
So fundamentally, we need to make a decision on how we want to handle
these. Richard seemed to prefer not having pass-xyz.h files if possible,
and that means in my tree-outrof-ssa case, the single external consumer
can just keep the prototype local. If there is more than one consumer,
it should be in a header.
Or we ban that practice and make a .h file for any .c file which exports
something.... and try to enforce a rule that prototypes required by a
.c file comes from an appropriate header file associated with the
originating source file... so no local prototypes for external functions.