On 11/05/13 09:26, Andrew MacLeod wrote:
On 10/30/2013 11:18 PM, 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.
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 decided to name the new file gimple-expr.[ch] instead of
gimple-decl.... This will eventually split into gimple-type.[ch],
gimple-decl.[ch], and gimple-expr.[ch]. I could split them that way now
if desired, but isn't critical yet. maybe I should just do that...
Anyway, of the 3 files, gimple-expr will depend on the other 2, and thus
is likely to be the one #included in places like the rtl generation
files that need access to all these gimple dictionary/expression
routines. (eventually those rtl files will include only gimple-expr.h
and not tree.h :-).
In any case, I had to do this split from gimple.h first since
gimple-stmt.[ch] and the others require some of these basic routines,
and I can't split anything else out first without then getting an
include dependency cycle between gimple.h and gimple-stmt.h for
instance. This way gimple-stmt.h can include gimple-expr.h, and then
gimple.h can include gimpe-stmt.h and no chicken/egg situation.
This contains just the functions that are in either in, or prototyped
in, gimple.h, and is just the first cut. There are more things that
will eventually get put here from gimple.c, but their prototypes are in
places like tree.h and more include cycles or poor requirements on files
to include are exposed if I move them now since front ends or rtl files
are using those routines (like get_base_address). There are also a few
I wanted to hold off on and see how things work out before moving them.
In any case, I tried to pull out the functions that operated on trees
currently and performed an operation on a type, decl, or expression. My
litmus test was usually, "Is this liekly going to be a method of a type,
decl or expr class relating to the object itself." and moved it if it
seemed so.
The slightly iffier ones were extract_ops_from_tree*() and
gimple_cond_get_ops_from_tree()... Those clearly worked on expressions
and not statements, but are utilized in places like rtl land that don't
deal with stmts... so they need to be exposed via the expression
processing and interface. Its also quite possible those will end up in
gimplify.[ch] once I get that far...
I do expect there will still be a little bit of fine tuning, but this is
the first cut to enable me to split out gimple-stmts.[ch] next.
Bootstraps on x86_64-unknown-linux-gnu with no new regressions. OK?
OK.
jeff
