On 09/05/2013 05:53 PM, Steven Bosscher wrote:
On Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod <amacl...@redhat.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
header file.
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
client's?
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).
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
clump.
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 :-)
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.
IIf I were to create a tree-ssa-ter.h file, then Id just leave the
prototype in tree-ssa-ter.h :-)
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.
Andrew
