On Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 09/05/2013 09:08 AM, Richard Biener wrote: >> >> On Thu, Sep 5, 2013 at 2:57 PM, Andrew MacLeod <amacl...@redhat.com> >> 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 ;) >> >> > ok, so to dwell on header file cleanup. When creating new header files for > say, tree-ssa-ter.h, what other include files should we make assumptions > have already been included... or should we make none? > For instance, the header files tree-ssa-ter.h would require system.h, > bitmap.h, tree-ssa-live.h, and gimple.h (soon to be gimple-core.h I hope :-) > to parse the prototypes
Most of the GCC headerfiles do not include all their required headers but rely on .c files doing that (in the appropriate order). I somehow like that though I cannot explain why ;) Also grepping for #includes I see that this doesn't seem to be true anymore. Certainly the issue is that we have multi-purpose headers where the subset used by .c files would not require all header dependencies of that header to be included. Which of course simply asks for a more functional split of the header. Richard. > > It seems that it should include them all, otherwise we are lying :-). And > the Makefile should reflect that. > > On the other hand, it should never be included in an environment where > system.h and gimple.h are not already available... so we could almost know > those are available... and not have to go out and read those include files > over again... > > Of course, trimming the .c file include list with some intelligence would > help minimize this, but not completely eliminate it. > > I'd say just expose everything properly and try to make the include lists > better. (ie include tree-ssa-ter.h, but not the files it includes) > Andrew > > PS > thats just an example, I don't think we need a tree-ssa-ter.h. There are > only 3 exported functions. 2 are used exclusively in tree-outof-ssa.c and > one is used in expr.c (a reuse of the is_replaceable_p function.) > The 2 that are exclusive to tree-out-ssa.c could simple have the prototypes > in tree-outof-ssa.c, That seems like the best thing to do for single > client's? > The other function could be moved from tree-ssa-ter.c to expr.c, and the > prototype exported in expr.h and used in tree-ssa-ter.c > >
