Hopefully the other attempts to send this aren't queued up... in any
case, maybe I can't even attach a .dot file?... So no attachments this
time...
instead, the diagram is here:
http://gcc.gnu.org/wiki/rearch?action=AttachFile&do=view&target=gimple.png
-------------------------------------------------------------
I've made 4 attempts now to split gimple.[ch] into reasonable component
parts, and I've finally found something that I can make work and fits my
plans.
I've attached a diagram to (hopefully :-) clarify things.
The original purpose of gimple.[ch] was to provide gimple statements.
This replaces the tcc_statement tree kind during the gimplification
process. No other tree kinds have been converted to gimple
structs/classes. That what the next stage of my project will do.
As a result, any gimple queries regarding types, decls, or expressions
are actually tree queries. They are sprinkled throughout gimple.[ch] and
gimplify.[ch], not to mention tree.[ch] as well as other parts of the
compiler where they happened to be needed. This has caused various
ordering issues among the inline functions when I tried to split out the
stmt, iterator, and gimplification bits from gimple.[ch]. Not to
mention a lack of an obvious home for some of these functions.
I'd like to move these as I encounter them into a new file,
gimple-decl.[ch]. When I'm working on the other gimple classes, this
will be further split into gimple-decl, gimple-type and gimple-expr as
appropriate but it seems reasonable to create just the one file now to
clump them since there is no other formal organization. So any function
which is actually querying/setting/building a decl, type, or expression
for gimple would go here.
I also want to split out the structure and accessing bits of the gimple
statement structure into gimple-stmt.[ch]. This would be just the
struct decls as well as all the accessing/setting/building functions...
The gimple_stmt_iterators (gsi) themselves also break out into their own
file quite naturally.
I find that gimple_seq does not seem to be a very clearly defined
thing. Although a gimple_seq is just a typedef for a gimple stmt (I
thought it use to be a container?), it provides some additional
statement queuing functionality. Ie, you don't have to worry about
next and prev pointers in the stmt's you build, you simply queue them up
and attach them where you want. In that sense, its a kind of overlay on
top of a gimple-stmt as it provides additional functionality.
gimple_seq also utilizes gimple_smt_iterators under the covers. They do
not expose the iterators to a function using a gimple_seq but they do
need that knowledge to mange the lists under the covers (thus a dashed
line in the diagram).
Its unclear to me whether gimple_seq's are intended to have a future, or
whether their functionality should be rolled right into statements
themselves. I believe it may be possible to include gimple-iterator.h
in gimple-stmt.c to provide the implementation without affecting the
inheritance layout, although I haven't actually tried that path.
Or we can treat them as a different layer with their own gimple-seq.[ch]
files.
Or we could combine gimple_seq and gsi routines in the same file, but
that would have the downside of exposing the gsi routines to the
gimplifier, which should have no need of. Either of the latter 2
options seem reasonable to me for now.
The remnants of gimple.[ch] would contain various general helper
routines (walkers, etc), much like tree-ssa.[ch] does for ssa.
And finally gimplify.[ch] would contain all the stuff required for the
front ends to generate gimple code. This is actually a front end
interface. At the moment it isn't obvious since all the current gimple
code also uses trees and calls the gimplifier frequently. As I push
gimple types and decls into the back end and remove trees, the backend
should simply generate gimple directly. Gimplify should slowly become
usable only via tree based front ends... (Thus the dotted line from BE
to gimplify.. it should be removed eventually)
Which means that all the front end files should be including *only*
gimplify.h, and getting everything they need from there. Currently a
number of them include gimple.h which should not be required.
How reasonable or unreasonable does this sound? :-) I've been tearing
the file apart in different ways and orders, and this seems to be the
most workable solution I have come up with that doesn't involve hacks.
Andrew
