On Aug 21, 2013, at 10:23 AM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 08/10/2013 06:03 AM, Richard Biener wrote: >> Mike Stump <mikest...@comcast.net> wrote: >>> On Aug 9, 2013, at 3:36 PM, Diego Novillo <dnovi...@google.com> 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.h >>>> >>>> - 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. >> 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. >> > > the reason for the tri-split is because many of the "appropriate" places for > function prototypes don't exist yet... they were thrown in tree.h or > tree-flow.h because no one wanted to create a small header file as an > appropriate place, or was too lazy to figure it out.
Ok. But creating a new bad place for them to live, just to eject them from tree.h, is wasteful. Design a better spot that is good, then make it happen. tree-api.h isn't good. It is just another random stop-gap; let's live with the tree.h random stop-gap. When you are done with stop gaps, then move them. > The idea here is to get all those into a file of their own so they can then > be dealt with later, but not impact the code base much. They don't need any > of the tree accessor macros, nor even the tree structural content, just the > "struct tree *" from core-types. . This means the tree-api.h file can be > included by tree.h for untouched files, and can also be included from > gimple.h for those which have been converted and no longer include tree.h. > Leaving them in tree.h defeats the purpose of the split since tree.h would > have to be included by files using gimple.h in order to see the prototypes.. > and that would then bring in all the tree macros again. No. tree-core.h has the api and the data structures. gimple.h uses this, as it wants all in it. gimple.h doesn't use tree.h, as it doesn't want the macro and any other content you want to exclude. This is two use cases, so, two files. > So really, the content of tree-macro.h should be called tree.h, Yes. > that should include the tree-core.h file as well as the tree-api.h file. No… I don't see a client for tree-api. Logically, you can segregate them down at the bottom of tree-core.h. > We are then left with this tree-api.h file which will be included from 2 > places.. tree.h and gimple.h. As files are converted to the new gimple > form, any functions which use to have 'tree' in the prototype are going to be > converted to GimpleType or whatever, and the tree prototype(s) will be > removed from tree-api.h. At that point, the prototype(s) will be put in an > appropriate header file, creating one if need be, and included as needed. One can move them from tree-core.h or to any other home as appropriate.
