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?

Andrew