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 - Refactor tree.h


On 08/10/2013 06:03 AM, Richard Biener wrote:
Mike Stump <mikestump@comcast.net> wrote:
On Aug 9, 2013, at 3:36 PM, Diego Novillo <dnovillo@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.

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.

So really, the content of tree-macro.h should be called tree.h, and that should include the tree-core.h file as well as the tree-api.h file. Then all existing files which include tree.h get exactly what they have today.

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.

So that is my rationale for the 3 way split of tree.h I proposed to Diego.

We could do that tree-api work upfront.. everything that is in tree-api.h could be given a new home, which would require creating some more header files and changing the #include footprint in various files. I was just trying to minimize the turmoil in the 4.9 source base... :-)

Andrew



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