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]

Re: RFC - Next refactoring steps

On 09/06/2013 09:09 AM, Michael Matz wrote:

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
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
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
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.

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