On 10/30/13 20:26, Andrew MacLeod wrote:
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.
Yup. The problems are similar to what I was struggling with when I
wanted to move infer_nonnull_value and one of its children out of
tree-vrp :-)
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.
Seems reasonable.
Or we can treat them as a different layer with their own gimple-seq.[ch]
files.
No real opinions on this -- primarily because I haven't had to muck
around with the gimple_seq stuff.
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.
I've also attached the .dot file in case anyone wants to suggest
something different via a diagram.
This all seems pretty reasonable to me. I don't see anything that makes
me say WTF (at least in terms of where you're trying to go). And I
think we can fine tune it a bit as we go, say if we decide to do
something different with gimple_seq.
Jeff
