RFC - Refactor tree.h

[Andrew MacLeod]

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