This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC - Next refactoring steps
- From: Michael Matz <matz at suse dot de>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Diego Novillo <dnovillo at google dot com>, Mike Stump <mikestump at comcast dot net>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 6 Sep 2013 15:09:38 +0200 (CEST)
- Subject: Re: RFC - Next refactoring steps
- Authentication-results: sourceware.org; auth=none
- 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> <52161471 dot 6040408 at redhat dot com> <CAD_=9DTQhKGQHn6KgGJg9bQN9_Ft5DaE3fKJr8OuaALhjQSy+g at mail dot gmail dot com> <CAFiYyc3Tc24A5LExuvOKH_poXqYyJ_GUE8-CbxK1cMnY2VPmUQ at mail dot gmail dot com> <52287FD3 dot 4040204 at redhat dot com>
Hi,
On Thu, 5 Sep 2013, Andrew MacLeod wrote:
> 1 - I think we ought to split out the data structures from gimple.h into
> gimple-core.h, like we did with tree.h
Why?
> gimple.h. That won't really affect my work. I think it probably ought to be
> done for clarity eventually. gimple.h would then simply become a collector
> of "gimple-blah.h" files which are required for a complete gimple system.
Doesn't make sense to me. If you split it into multiple files, just to
then create a wrapper called gimple.h including all of them again for the
consumers you can just as well have all of it in one file.
> 2 - all the uses of TREE_NULL to refer to an empty/nonexistent object... it
> is no longer in tree-core.h, which I think is correct. what should we start
> using instead in converted files? options are:
> a) 0
> b) NULL
> c) something we define as 0, like GIMPLE_NULL
I think I'd prefer 0, but it creates a problem with varargs functions, so
you'd always need "(gimple)0" for those, which you'd probably hide behind
a macro, at which point you'd have two forms for the nil gimple ("0" and
that macro), for consistency you'd want to use the macro in place of "0"
also in the non-varargs places, et voila, you're back to "NULL" or
"NULL_GIMPLE" :-/
> 3) remove tree.h from other .h files
> Now that tree.h is split, there are a few .h files which directly include
> tree.h themselves. It would be nice if we could remove the implementation
> requirement of tree.h to ease moving to gimple.h. The 4 files are :
> ipa-utils.h lto-streamer.h streamer-hooks.h tree-streamer.h
> It should be possible to not directly include tree.h itself in these files.
> Worst case, the header file is included after tree.h from the .C files.. that
> seems to be the way most of the other include files avoid including tree.h
> directly.
That can be done right now I think.
For the rest of the topic, tree vs gimple: I don't see much value in that.
Why create a gimple_expr type that basically is just tree? You can as
well use tree then.
Ciao,
Michael.