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.
