This is the mail archive of the
mailing list for the GCC project.
Re: [patch 1/2] tree-flow.h restructuring
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Diego Novillo <dnovillo at google dot com>
- Date: Wed, 11 Sep 2013 08:30:17 -0400
- Subject: Re: [patch 1/2] tree-flow.h restructuring
- Authentication-results: sourceware.org; auth=none
- References: <522F70C3 dot 8080906 at redhat dot com> <CAFiYyc2cWVVRc350-rU6bQV7-f750=QWenmpaSk_sbrS2eHWsA at mail dot gmail dot com>
On 09/11/2013 04:45 AM, Richard Biener wrote:
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.
On Tue, Sep 10, 2013 at 9:19 PM, Andrew MacLeod <firstname.lastname@example.org> 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...?
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
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-*
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.
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).
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
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