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.
