Re: RFC - Next refactoring steps
On Thu, Sep 5, 2013 at 11:53 PM, Steven Bosscher stevenb@gmail.com wrote: On Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod amacl...@redhat.com wrote: 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 Why bitmap.h? bitmap is in coretypes.h. Anyway, a little more side-stepping: on my wishlist is making the various data types (sbitmap, bitmap, sparseset, etc.) independent of gcc headers as much as possible, and having a single header, gccadt.h say, that provides most/all generic data structures (e.g. also including hash tables). Yeah, and we could move all the files into a lib/ subdirectory (well, or make them part of libiberty). Of course, trimming the .c file include list with some intelligence would help minimize this, but not completely eliminate it. As you may have noticed, I tried trimming the #include lists in many .c files last year. It's a hard but worthwhile job: You find some headers have to be included before others, or some headers are used by some .c file but they don't #include it. Instead they receive it through an #include in some .h file but nothing defined directly, i.e. not via #include, is used in the .c file. 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? Not really. It's a single client now, but if it's an exported interface of some kind, then why should its use stay limited to a single client? Either some function is exported and therefore should have a prototype in a .h file, or something is local to a file and no prototype is necessary (in most cases anyway). 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 Makes sense. Ciao! Steven
Re: RFC - Next refactoring steps
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
Re: RFC - Next refactoring steps
On Sep 5, 2013, at 11:54 PM, Richard Biener richard.guent...@gmail.com wrote: 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 ;) Very old school. I can explain why I don't like it, but I'll resist. The universal standard is for each header to include all it needs and for the ordering of includes not to matter any. Deviations from this are the exception and should virtually never should be the case. Also grepping for #includes I see that this doesn't seem to be true anymore. Yeah, everyone else hates the old school style with a passion, it was never a good idea. :-) When they come across it, people have a tendency to fix the headers as broken and over time, all the dependencies eventually get added.
Re: RFC - Next refactoring steps
On Fri, Sep 6, 2013 at 10:14 AM, Mike Stump mikest...@comcast.net wrote: On Sep 5, 2013, at 11:54 PM, Richard Biener richard.guent...@gmail.com wrote: 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 ;) Very old school. I can explain why I don't like it, but I'll resist. The universal standard is for each header to include all it needs and for the ordering of includes not to matter any. Deviations from this are the exception and should virtually never should be the case. Also grepping for #includes I see that this doesn't seem to be true anymore. Yeah, everyone else hates the old school style with a passion, it was never a good idea. :-) When they come across it, people have a tendency to fix the headers as broken and over time, all the dependencies eventually get added. Well, I still think you cannot randomly change include file order in GCC. At least some #ifdef ... hackery in some headers will suddenly break (that is, change outcome) if you include for example tm.h before or after it. But yes, making all dependencies explicit puts #includes where they belong and shows where header refactoring would make sense. It also removes weird includes from .c files that are only necessary to make included required headers not break. Richard.
Re: RFC - Next refactoring steps
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.
Re: RFC - Next refactoring steps
On 09/06/2013 09:09 AM, Michael Matz wrote: 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? For the seam reason we split tree.h. The new gimple mechanism needs to coexist with trees until the conversion is complete. There will be a period of time when some files have been converted over to the new gimple wrappers, and they will export functions which unconverted files still need to call. The functional prototypes will be using things like GimpleType, so those files will need to see the basic class description to compile and call the routine. (just like how the gimple function need to see the baic layout of a tree to interact with trees) They don't need to see all the implementation for the methods in gimple-type.h, but they need to see the basic class description which also contains the few routines required to cast back and forth to tree. This allows both to coexist while we transition. Doing it now before we branch into stage 2 makes life much easier in the branch I will be working on during stage2, as well as test the functionality of it with the rest of the refactoring we are doing before the branch. 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. Well, gimple.h right now is 5400 lines, and that just implements gimple statements. when we add the methods for types and decls and expression etc etc etc, its going to be a very very very large file. The split is to make it managable. Im fine with leaving gimple.h to be the statement implementation, and then the top of gimple.h can just include all the other ones... it just means gimple-stmt is gimple... Its just a consistency naming thing, and i don't feel strongly about it. 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 :-/ I prefer 0 too I think, but I had forgotten about vararg issues... so are we thinking maybe just plain old NULL? I guess thats pretty standard.. 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. Because once its all done... we can do many other things because the uses are detached from the implementation. In a gimple expression we can see concisely what elements of tree are actually used, and how. We can then remove tree from the implementation of gimple_expr if it makes sense. We can change the underlying object from a tree to something which more concisely represents what we need in the middle/back end. We can easily change the implementation of gimpe-expr to use an index into a table of expressions which makes streaming much simpler.. I am also doing this for types and decls and such. We get typesafe checking at compile time, And the ultimate goal is to remove dependencies from the front end and the gimple... gimple will be detachable from trees. All the fun stuff I talked about in the original document motivating this.
Re: RFC - Next refactoring steps
On 09/06/2013 04:19 AM, Richard Biener wrote: On Fri, Sep 6, 2013 at 10:14 AM, Mike Stump mikest...@comcast.net wrote: On Sep 5, 2013, at 11:54 PM, Richard Biener richard.guent...@gmail.com wrote: 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 ;) Very old school. I can explain why I don't like it, but I'll resist. The universal standard is for each header to include all it needs and for the ordering of includes not to matter any. Deviations from this are the exception and should virtually never should be the case. Also grepping for #includes I see that this doesn't seem to be true anymore. Yeah, everyone else hates the old school style with a passion, it was never a good idea. :-) When they come across it, people have a tendency to fix the headers as broken and over time, all the dependencies eventually get added. Well, I still think you cannot randomly change include file order in GCC. At least some #ifdef ... hackery in some headers will suddenly break (that is, change outcome) if you include for example tm.h before or after it. these would be really good to identify and fix, if possible. (surely they can be fixed.. :-)if they cant be fixed for whatever reason, we ought to protect them with some mechanism.. ie assert that tm.h either has or has not been included before hand... whichever way is required. At least then we get an error if it changes. Do you know of any of the top of your head? Andrew
Re: RFC - Next refactoring steps
On 09/05/2013 08:26 PM, Joseph S. Myers wrote: On Thu, 5 Sep 2013, Andrew MacLeod wrote: Or are you suggesting that coretypes.h is a file we can assume is available? Every .c file should start with includes of config.h, system.h and coretypes.h, in that order, so all other headers can assume they have been included. OK, I can work with those assumptions :-). Andrew
Re: RFC - Next refactoring steps
On Fri, 6 Sep 2013, Richard Biener wrote: But yes, making all dependencies explicit puts #includes where they belong and shows where header refactoring would make sense. It also removes weird includes from .c files that are only necessary to make included required headers not break. One difficulty is that e.g. flags.h uses SWITCHABLE_TARGET (tm.h) but is included in lots of front-end files that don't actually care about the SWITCHABLE_TARGET use in flags.h and have no other reason to include tm.h. Since we generally want to eliminate tm.h uses in front-end files (converting target macros used there into hooks, etc.), making the dependency explicit in the obvious way isn't such a good idea. Instead, probably the bits that don't depend on SWITCHABLE_TARGET should move out of flags.h to other headers, the residual bit that does depend on tm.h should become e.g. switchable-target-flags.h (and include tm.h), and files that currently include flags.h should change to including the generated options.h (and any other headers needed for things formerly got from flags.h). (If other headers do start including tm.h, of course it becomes more complicated to identify which front-end files are still including tm.h, as they may include it indirectly.) -- Joseph S. Myers jos...@codesourcery.com
Re: RFC - Next refactoring steps
On Fri, Sep 6, 2013 at 5:21 PM, Andrew MacLeod wrote: hackery in some headers will suddenly break (that is, change outcome) if you include for example tm.h before or after it. these would be really good to identify and fix, if possible. (surely they can be fixed.. :-)if they cant be fixed for whatever reason, we ought to protect them with some mechanism.. ie assert that tm.h either has or has not been included before hand... whichever way is required. At least then we get an error if it changes. Do you know of any of the top of your head? sched-int.h comes to mind as an example I fixed recently (it needs INSN_SCHEDULING from insn-attr.h. But these cases are hard to discover. Usually you simply run into them while trying to re-arrange the #includes of a .c file. Ciao! Steven
Re: RFC - Next refactoring steps
On Fri, Sep 6, 2013 at 4:14 AM, Mike Stump mikest...@comcast.net wrote: On Sep 5, 2013, at 11:54 PM, Richard Biener richard.guent...@gmail.com wrote: 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 ;) Very old school. I can explain why I don't like it, but I'll resist. The universal standard is for each header to include all it needs and for the ordering of includes not to matter any. Deviations from this are the exception and should virtually never should be the case. Agreed. Header files should be self-contained and include everything they need. This will be increasingly more important in the presence of C++ modules. Diego.
Re: RFC - Next refactoring steps
On Sep 6, 2013, at 8:21 AM, Andrew MacLeod amacl...@redhat.com wrote:
these would be really good to identify and fix, if possible.
Do you know of any of the top of your head?
Sure, they are easy to find. See below. I'll note one more use of fixing
these. clang is adding modules to get compilation speed. Modules require that
the inclusion of a header be the same in every instance that it is used. The
usages below would prevent these headers from participating in being a module
(and transitive closure of all they include them), thus dooming the software to
slow compiles. C++ features exponential compile time, where/as C features
logarithmic compile time. modules return things back to being linear and are
worthwhile to control compilation speed issues. To be competitive, I think gcc
will have to add modules eventually as well, and as the gcc source base grows,
making use of modules to keep compilation time down is also worthwhile.
dfp.h:
#ifdef TREE_CODE
bool decimal_real_arithmetic (REAL_VALUE_TYPE *, enum tree_code, const
REAL_VALUE_TYPE *,
const REAL_VALUE_TYPE *);
#endif
double-int.h:
#ifndef GENERATOR_FILE
/* Conversion to and from GMP integer representations. */
void mpz_set_double_int (mpz_t, double_int, bool);
double_int mpz_get_double_int (const_tree, mpz_t, bool);
#endif
expr.h:
#ifdef TREE_CODE
extern rtx expand_variable_shift (enum tree_code, enum machine_mode,
rtx, tree, rtx, int);
extern rtx expand_shift (enum tree_code, enum machine_mode, rtx, int, rtx,
int);
extern rtx expand_divmod (int, enum tree_code, enum machine_mode, rtx, rtx,
rtx, int);
#endif
function.h:
#ifdef RTX_CODE
extern void diddle_return_value (void (*)(rtx, void*), void*);
extern void clobber_return_register (void);
#endif
target.h:
#ifdef GCC_TM_H
#ifndef CUMULATIVE_ARGS_MAGIC
#define CUMULATIVE_ARGS_MAGIC ((void *) targetm.calls)
#endif
static inline CUMULATIVE_ARGS *
get_cumulative_args (cumulative_args_t arg)
{
#ifdef ENABLE_CHECKING
gcc_assert (arg.magic == CUMULATIVE_ARGS_MAGIC);
#endif /* ENABLE_CHECKING */
return (CUMULATIVE_ARGS *) arg.p;
}
Re: RFC - Next refactoring steps
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 ;) Richard. 1 - I think we ought to split out the data structures from gimple.h into gimple-core.h, like we did with tree.h What is left as gimple.[ch] which should really be called gimple-stmt.[ch] since it implements just the tcc_statement class of trees. we could do that change now, or I'm ok leaving it like that for a while since I can just include gimple-type.h and gimple-decl.h and other new files from the top of 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. 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 prefer a) I think, since its consistent with things like if (!ptr), but b) is fine as well. I'm not too fond of option c). I figured we'd see what others like... maybe something else? :-) 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. 4 - Access to tree checking. Since trees are still being used under the covers, we still need to be able to do tree_checking... I dont think we need the tree checking macros per se, but I do need access to the same basic checking functions.. like tree_check, tree-check2, tree_check_failed, etc. the basic inline tree_check* set of functions use TREE_CODE, so having access to them is no good anyway from a gimple.h file, so I pretty much need to rewrite those functions for gimple use, but there are a bunch of routines in tree.c that I still need the prototypes for. Things like tree_class_check_failed() and tree_contains_struct_check_failed(). I dont see the point ina speerate header file for those, but maybe we could put the prototypes in tree-core.h. I dont think I like that either.. but it is an option. 5 - This is more of a meta subject. but is on the radar and relates to the tree-checking issue. There is still some interface stuff from trees that is required by the gimple system, and will be as long as trees are used under the covers. For example, tree.h defines STRIP_NOPS() which is used in a lot of places. Say we add a strip_nops() method to the GimpleExpression class. gimple-expr.h needs to implement that functionality, but can't access tree.h. tree.h defines STRIP_NOPS as (EXP) = tree_strip_nop_conversions (CONST_CAST_TREE (EXP)) tree_strip_nop_conversions() is defined in tree.c and the protoype is in tree.h.. where it belongs. So there is no way to access this function call within a file converted to gimple. So, we need the prototype somewhere we can get at it and call it from strip_nops(). Other examples are the tree build routines. From gimple converted files, we still need to be able to build trees under the covers. The interface will building gimple expressions, but under the covers the gimple implementation needs to be able to access those build routines. One thought I had was to provide a gimple-tree.[ch] files which wrap up all these sorts of issues in one place. The gimple-tree.h file provides a gimple-only interface via prototypes to something like: void gimple_strip_nops (GimpleValue Expr); GimpleValue gimple_build_expression2 (GimpleCode code, GimpleValue Expr1, GimpleValue Expr2); Then in gimple-tree.c we break the rules. This one .c file would include tree.h so that it has access to all the tree stuff, and provides implementations of these functions. This would be
Re: RFC - Next refactoring steps
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 ;) Richard. 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, but... 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. Andrew
Re: RFC - Next refactoring steps
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 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
Re: RFC - Next refactoring steps
On Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod amacl...@redhat.com wrote: 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 Why bitmap.h? bitmap is in coretypes.h. Anyway, a little more side-stepping: on my wishlist is making the various data types (sbitmap, bitmap, sparseset, etc.) independent of gcc headers as much as possible, and having a single header, gccadt.h say, that provides most/all generic data structures (e.g. also including hash tables). Of course, trimming the .c file include list with some intelligence would help minimize this, but not completely eliminate it. As you may have noticed, I tried trimming the #include lists in many .c files last year. It's a hard but worthwhile job: You find some headers have to be included before others, or some headers are used by some .c file but they don't #include it. Instead they receive it through an #include in some .h file but nothing defined directly, i.e. not via #include, is used in the .c file. 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? Not really. It's a single client now, but if it's an exported interface of some kind, then why should its use stay limited to a single client? Either some function is exported and therefore should have a prototype in a .h file, or something is local to a file and no prototype is necessary (in most cases anyway). 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 Makes sense. Ciao! Steven
Re: RFC - Next refactoring steps
On 09/05/2013 05:53 PM, Steven Bosscher wrote: On Thu, Sep 5, 2013 at 5:47 PM, Andrew MacLeod amacl...@redhat.com wrote: 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 Why bitmap.h? bitmap is in coretypes.h. well, only because a function prototype used the bitmap type... I suppose you could include coretypes.h, but then you get even more stuff included. I was making the list the minimal required to compile the header file. Or are you suggesting that coretypes.h is a file we can assume is available? that seems like a bit of a slippery slope, but we could pick a few. I prefer it be explicit myself. As you may have noticed, I tried trimming the #include lists in many .c files last year. It's a hard but worthwhile job: You find some headers have to be included before others, or some headers are used by some .c file but they don't #include it. Instead they receive it through an #include in some .h file but nothing defined directly, i.e. not via #include, is used in the .c file. 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? Not really. It's a single client now, but if it's an exported interface of some kind, then why should its use stay limited to a single client? Either some function is exported and therefore should have a prototype in a .h file, or something is local to a file and no prototype is necessary (in most cases anyway). Its exported only because the original file was split for modularity reasons., otherwise tree-outof-ssa.c would be much larger. If we had such a think as a module clump, it would only be visible inside that clump. If we go down the path of its external so it it should be in a header file, then we will probably need to have pass-xyz.h header files.. ie, I would be creating a tree-ssa-ter.h file to put 2 externals in that are only used by tree-outof-ssa.c. a small sortof useless header file we don't actually need. it is cleaner than in putting it in tree-flow.h of course :-) 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 Makes sense. IIf I were to create a tree-ssa-ter.h file, then Id just leave the prototype in tree-ssa-ter.h :-) So fundamentally, we need to make a decision on how we want to handle these. Richard seemed to prefer not having pass-xyz.h files if possible, and that means in my tree-outrof-ssa case, the single external consumer can just keep the prototype local. If there is more than one consumer, it should be in a header. Or we ban that practice and make a .h file for any .c file which exports something and try to enforce a rule that prototypes required by a .c file comes from an appropriate header file associated with the originating source file... so no local prototypes for external functions. Andrew
Re: RFC - Next refactoring steps
On Fri, Sep 6, 2013 at 12:22 AM, Andrew MacLeod wrote: Or are you suggesting that coretypes.h is a file we can assume is available? that seems like a bit of a slippery slope, but we could pick a few. I prefer it be explicit myself. coretypes.h is available. Why do you think that's a slippery slope? The name of this header file already suggests its purpose: Define the core types - to *avoid* having to include files like bitmap.h if you really only want struct bitmap_head; typedef struct bitmap_head *bitmap;. Ciao! Steven
Re: RFC - Next refactoring steps
On 09/05/2013 06:38 PM, Steven Bosscher wrote: On Fri, Sep 6, 2013 at 12:22 AM, Andrew MacLeod wrote: Or are you suggesting that coretypes.h is a file we can assume is available? that seems like a bit of a slippery slope, but we could pick a few. I prefer it be explicit myself. coretypes.h is available. Why do you think that's a slippery slope? The name of this header file already suggests its purpose: Define the core types - to *avoid* having to include files like bitmap.h if you really only want struct bitmap_head; typedef struct bitmap_head *bitmap;. yeah, coretypes.h wouldn't be a slipperly slope... so in this case it would be coretype.h which is included not bitmap.h in the header file Andrew
Re: RFC - Next refactoring steps
On Thu, 5 Sep 2013, Andrew MacLeod wrote: Or are you suggesting that coretypes.h is a file we can assume is available? Every .c file should start with includes of config.h, system.h and coretypes.h, in that order, so all other headers can assume they have been included. (In principle I think coretypes.h should be split up so that files included in the driver don't see at all, even through minimal coretypes.h declarations, types such as tree that don't make sense in the driver. But that probably requires splitting up various other headers, and I don't think it's a priority.) -- Joseph S. Myers jos...@codesourcery.com
