This is the mail archive of the
mailing list for the GCC project.
Re: RFC - Refactor tree.h
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Mike Stump <mikestump at comcast dot net>,Diego Novillo <dnovillo at google dot com>
- Cc: Andrew Macleod <amacleod at redhat dot com>,gcc-patches at gcc dot gnu dot org
- Date: Sat, 10 Aug 2013 12:03:00 +0200
- Subject: Re: RFC - Refactor tree.h
- References: <20130809223645 dot GA22559 at google dot com> <48A1A20B-1DF2-45A5-9CB6-13CDC6A89A4F at comcast dot net>
Mike Stump <email@example.com> wrote:
>On Aug 9, 2013, at 3:36 PM, Diego Novillo <firstname.lastname@example.org> wrote:
>> This patch is still WIP. It builds stage1, but I'm getting ICEs
>> during stage 2.
>> The patch splits tree.h into three files:
>> - tree-core.h: All data structures, enums and typedefs from
>> - tree-api.h: All extern function definitions from tree.h
>> - tree-macros.h: All macro accessors, tree checks and other
>> inline functions.
>I don't like this split. You focus in on the details and sort code by
>detail. I think this is wrong. I want code sorted by the features and
>functions it provides, and all like this, go into explainable
>functional bins. One day, a function might be implemented by a data
>structure, the next day, by a routine, or a macro, or an inline
>function, the form of it doesn't matter.
>It is like sorting routines by the first character of the spelling of
>the name of the routine. tree_to_int, goes into t.c, because tree
>starts with a t. You rename the function, and suddenly it moves files?
>Examine double_int. All macros for double int, go in double-int.h or
>double-int.c. All function go in one or the other. All routines goes
>in one or the other. All double-int code goes into this bin. What bin
>is it? macros? No, the bin is double-int.
>Likewise vec.[ch]. You want tree.h smaller, pick the largest abstract
>group that is contained in that file, and remove it to it's own file.
>For example, fold. fold is fold, fold is special. fold can be in
>fold.h. If you examine the nature of the code in tree.h:
>/* In fold-const.c */
>/* Non-zero if we are folding constants inside an initializer; zero
> otherwise. */
>extern int folding_initializer;
>This is a dead giveaway. The second giveaway, fold-const.c exists.
>That code isn't in tree.c. Now, maybe you call it fold-const.h, maybe
>that's better, you get the idea.
>Look for isolatable hunks that can exist in their own group of some
>sort. Look for "/* In ", this is a better way to sort.
I mostly agree - tree-macros.h is a red herring. It should be tree-core.h and tree.h only. What does not belong there should go to other appropriate places, like fold-const.h for example.