[patch 0/2] gcc re-arch status

[Andrew MacLeod]

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.
perfect.
> 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 
tree?

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.

Andrew