This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 09/11/2013 04:45 AM, Richard Biener wrote:
On Tue, Sep 10, 2013 at 9:19 PM, Andrew MacLeod <> 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
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]