This is the mail archive of the
mailing list for the GCC project.
Re: [patch 0/2] gcc re-arch status
- 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>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Fri, 18 Jul 2014 12:30:10 -0400
- Subject: Re: [patch 0/2] gcc re-arch status
- Authentication-results: sourceware.org; auth=none
- References: <53C5C15E dot 9000608 at redhat dot com> <CAFiYyc1tMaYwHWKT_JfP2XvzEyN1MD3T2dJW0=vFZ_snzhcetQ at mail dot gmail dot com>
On 07/17/2014 07:10 AM, Richard Biener wrote:
Just to mention - the "regimplification removal" and a "gimple-building
facility" is provided on the match-and-simplify branch worked on by
me and Prathamesh (a GSoC student this year). I'll present about
this during the Cauldron with the title "Unifying GENERIC and GIMPLE
folding with a pattern description". It falls under the folding umbrella
as the important feature passes get from using fold + re-gimplification
is expression simplification.
Another related topic (well, not so much maybe as you are focused
on removing references to "tree"s from GIMPLE) is (language dependent)
debug information for types and decls, esp. in the context of LTO
(but also in the context of information we need to retain during the
GIMPLE/RTL phases). Recently on IRC we concluded that the simplest
approach to start tackling this is to emit (aka run the dwarf2out machinery)
debug info for decls and types early (at least before LTO streaming).
To reference DIEs created there we annotate decls which we can
later complete (function and variable definitions) with hidden symbols
we need to remember for those entities (and stream them via LTO).
At LTO LTRANS time we build a DWARF translation unit importing
referenced units with decls/types from compile-time and complete
functions and variables, refering to the compile-time decl/type dwarf
via those symbols. And we of course link this "early" debug info
at link time. A similar scheme could be used even without LTO
(emit the early debug info into the asm early and later emit another blob ofA
debug info refering to it). Volunteers to prototype that welcome ;) (hah)
It would basically allow us to build a completely separate representation
for types (the "real" types, not 'tree') and decls on GIMPLE (yeah, really
no trees!), and Frontends like GFortran could emit this GIMPLE directly,
skipping GENERIC, if it knows to emit debug info itself.
This is worth discussing... Now that I have a mechanism which we can use
to remove all trees from GIMPLE, I'd like to discuss what trees are
actually useful to remove... if any.
The only trees that I think may make sense to replace at this point are
potentially types and decls. All the LTO work you guys have been doing
means you are the defacto experts on decls and types in the backend...
Would it buy us anything to have a custom type and/or decl kind that
exists from gimpification time on in the backend rather than the current
I believe LTO creates its own symbol table and type mapping/system but I
don't know much beyond that. Would it make sense if we could replicate
those throughout the backend and have those become the types and/or
decls? or some subset of the LTO stuff? We could potentially haul a
bunch of that stuff out of LTO and make it an integral part of the
backend.. and maybe we could integrate that debug info work you are
talking about into it.
I dont plan to present very much on sunday in the BOF. I'd like to
discuss what useful direction we can actually go.