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 0/2] gcc re-arch status

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 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.


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