This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC - Refactor tree.h
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Mike Stump <mikestump at comcast dot net>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Diego Novillo <dnovillo at google dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 22 Aug 2013 09:38:57 -0400
- Subject: Re: RFC - Refactor tree.h
- References: <20130809223645 dot GA22559 at google dot com> <48A1A20B-1DF2-45A5-9CB6-13CDC6A89A4F at comcast dot net> <cf6d07ba-b8bc-43c2-9f84-e7709ed7730e at email dot android dot com> <5214F775 dot 60702 at redhat dot com> <B962A2B6-233D-4B65-B4BF-CE1B20B0154B at comcast dot net>
On 08/21/2013 05:13 PM, Mike Stump wrote:
O
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.
OK, I see what you are saying, and it makes sense.
I was thinking there would be other uses for the tree-api.h file and
didn't want to pollute tree-core.h... for instance, the tree-builder
inline functions are going to need to be accessible in files which have
been converted as well, but I'll worry about that when I get to it... I
will likely create gimple object routines to do the equivalent anyway.
And I'll deal with anything else as it arises.
so we would have:
- tree-core.h which has the tree structure's first, then all the
prototypes at the end of that file which would have been in
tree-api.h In theory, these eventually all find better homes.
- tree.h which includes tree-core.h, then all the macros and such.
I can live with that, it enables what I need to do and has minimal impact.
Andrew