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 Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 09/05/2013 09:08 AM, Richard Biener wrote:
>>
>> On Thu, Sep 5, 2013 at 2:57 PM, Andrew MacLeod <amacleod@redhat.com>
>> wrote:
>>>
>>> Now that tree.h is split in two, there are some follow up things that
>>> will
>>> facilitate the deforestation of gimple.  I've also thrown in a couple of
>>> structuring issues for good measure.
>>>
>>> What are your thoughts on these subjects?
>>
>> Jumping in from the side I suggest you start de-foresting existing headers
>> where they say
>>
>> /* In foobar.c */
>> ...
>>
>> to simply add a foobar.h with the contents that follow.  Bonus points if
>> you
>> actually verify all definitions from X.c are declaed in X.h (the /* In ...
>> */
>> annotations are hopelessly out-of-date in some cases).
>>
>> More bonus points if you avoid pass-xyz.h files but instead move code
>> useful to multiple passes to more appropriate places.  That said,
>> definitely
>> avoid pass-xyz.h ;)
>>
>>
> 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

Most of the GCC headerfiles do not include all their required headers but
rely on .c files doing that (in the appropriate order).  I somehow like
that though I cannot explain why ;)  Also grepping for #includes I see
that this doesn't seem to be true anymore.  Certainly the issue is that
we have multi-purpose headers where the subset used by .c files
would not require all header dependencies of that header to be included.
Which of course simply asks for a more functional split of the header.

Richard.

>
> It seems that it should include them all, otherwise we are lying :-).  And
> the Makefile should reflect that.
>
> On the other hand, it should never be included in an environment where
> system.h and gimple.h are not already available...  so we could almost know
> those are available... and not have to go out and read those include files
> over again...
>
> Of course, trimming the .c file include list with some intelligence would
> help minimize this, but not completely eliminate it.
>
> I'd say just expose everything properly and try to make the include lists
> better. (ie include tree-ssa-ter.h, but not the files it includes)
> Andrew
>
> PS
> 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?
> 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
>
>


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