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.
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
