This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC - Next refactoring steps


On 09/05/2013 05:53 PM, Steven Bosscher wrote:
On Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod <amacleod@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]