This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC - Next refactoring steps

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?

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 the only place that tree.h is included in the gimple ecosystem. It has the drawback of an extra layer of functions calls for most things, but maybe thats ok for the abstraction

We could also put all the tree checking stuff here as an option. Provide a copy of the tree checking inlines in gimple-tree.h as well as the prototypes for the functions in tree.c

At least then all the overlap and ickyness ends up in one place... At least as a start

Any other thoughts on how to deal with this sort of thing?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]