Re: [patch 1/2] tree-flow.h restructuring

[Andrew MacLeod <amacleod at redhat dot com>]

On 09/11/2013 04:45 AM, Richard Biener wrote:
> On Tue, Sep 10, 2013 at 9:19 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> > Here's a start at restructuring the whole tree-flow.h mess that we created
> > back in the original wild west tree-ssa days.
> >
> > First, almost everyone includes tree-flow.h because it became the kitchen
> > sink of functionality.  Really, what we ought to have is a tree-ssa.h which
> > anything that uses basic tree-ssa functionality includes, and that'll be the
> > main include for SSA passes. Other prototypes and such should come from
> > other appropriate places. Doing this in one step is basically impossible. so
> > here is that first few steps, structured so that it's easier to review.
> >
> > I changed everywhere which includes tree-flow.h  to include tree-ssa.h
> > instead.   tree-ssa.h includes tree-flow.h first, which makes it
> > functionally the same from a compiling point of view.
> You mean that doing the restructure and only adding includes that are
> required to make compile work again wasn't feasible...?
Not really for this first split... eveyrthing that required tree-flow.h 
basically requires tree-ssa.h.     Once everything has been separated 
from tree-flow.h and put in their right places,  It's easy to see 
exactly which parts are required where, and  by tackling each .c file 
once that uses tree.ssa.h I can get it down the the bare bones for what 
was required from the original bloated tree-flow.h.
> > I also moved everything from tree-flow.h and tree-flow-inline.h that is
> > related to tree-ssa.c functions into tree-ssa.h.  There were also a few
> > function prototypes sprinkled in a  couple of other headers which I moved
> > into tree-ssa.h as well.  I have verified that every exported function in
> > tree-ssa.c has a proto in tree-ssa.h, and is listed in the same order as the
> > .h file.
> Note that in general there isn't a thing like "tree SSA" anymore - it's
> "GIMPLE SSA" now ;)  Not that we want gigantic renaming occuring now,
> just if you invent completely new .[ch] files then keep that in mind.

I considered just making it just ssa.h, but maybe this isn't the 
time...  Probably easier to do a mass rename very early in stage 1... 
until then I figure it probably makes sense to make the .h match the .c 
file..     yes, for a new pair, I'd not bother with tree-*
> That is, if you moved stuff to tree-ssa.h that has no definition in tree-ssa.c
> then I'd rather have a new gimple-ssa.h that doesn't have a corresponding
> .c file (for now).
Ah, i see.   Although mulling it over last night,  Im marginally in 
favour of having a separate .h for for each .c... Then things like 
tree-ssa-ununit.h which are only used in one or two places can simply be 
included in the one or two .c files they are required for.  That way we 
preserve tree-ssa.h to only include the "commonly required" .h files 
which 6 or more .c files require. (to pick an arbitrary number :-)   
This will help reduce the include web for rebuilding/compiling.  I also 
note your response in the other patch... First I will try to restructure 
whats in the file before resorting to a new .h file in these cases.      
I'll keep a gimple-ssa.h "aggregator" on the backburner until it looks 
like it will be needed.
> > Compiling this change indicated that there were a few files which required
> > functionality from tree-ssa.c which really don't belong there.  In
> > particular,  useless_type_conversion_p and types_compatible_p are used by
> > the C++ front end and other places which don't really care about SSA.  So I
> > moved them into more appropriate places... tree.c and tree.h
> Well, those functions are only valid when we are in GIMPLE (the GIMPLE
> type system is less strict than the GENERIC one), so tree.[ch] isn't
> appropriate.
> gimple.[ch] would be.  But I wonder where it's used from the FEs - that's surely
> looking wrong (unless it's in a langhook).  But yes, the functions are not
> in any way about SSA but only GIMPLE.

OK, that wasn't obvious from the function itself (it only ever deals 
with trees), but that being the case, I'll move them both to gimple.[ch] 
instead. That seems more appropriate and I will comment it as gimple 
compatible only.

Looks like there is a langhook...
c-family/c-common.c:      && lang_hooks.types_compatible_p (TREE_TYPE 
(t1), TREE_TYPE (t2)))

However each front end seems to provide their own version of 
types_compatible_p and use that... ( c_types_compatible_p and 
cxx_types_compatible_p).   lto.c has gimple_types_compatible_p()... but 
does also use types_compatible_p() in lto-symtab.c  :-P


Andrew