This is the mail archive of the
mailing list for the GCC project.
Re: RFC - Next refactoring steps
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: 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: Thu, 05 Sep 2013 09:25:32 -0400
- 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> <CAFiYyc0yGMVohSBVdpboTMeFw229DW3ZFbg_rUqSSWUvu0zFqg at mail dot gmail dot com>
On 09/05/2013 09:08 AM, Richard Biener wrote:
On Thu, Sep 5, 2013 at 2:57 PM, Andrew MacLeod <firstname.lastname@example.org> wrote:
Now that tree.h is split in two, there are some follow up things that will
facilitate the deforestation of gimple. I've also thrown in a couple of
structuring issues for good measure.
What are your thoughts on these subjects?
Jumping in from the side I suggest you start de-foresting existing headers
where they say
/* In foobar.c */
to simply add a foobar.h with the contents that follow. Bonus points if you
actually verify all definitions from X.c are declaed in X.h (the /* In ... */
annotations are hopelessly out-of-date in some cases).
More bonus points if you avoid pass-xyz.h files but instead move code
useful to multiple passes to more appropriate places. That said, definitely
avoid pass-xyz.h ;)
Yes, well that's high on the list too, I just hadnt given it a lot of
thought yet. Yes, thisbis probably the right thing to do. However, The
functions in tree.c that I need would then end up in tree.h... which
isnt good for me :-) we could have a tree-proto.h for just this one
file or something like that. I dont think tree-core is the right place,
Anyway, that would resolve the tree-checking and place to put protoypes
issue just fine. I'd definitely go for the bonus points :-). I also
think a lot of include files are including a lot of crud they dont need
too... In glancing at those 4 .h files that include tree.h, they have
along list of includes, most of which are also included in the .c
files. And many of those have #includes they don't need I bet. I'd
have alook at that on the way through the file too.