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.