On Wed, Jul 16, 2014 at 2:03 AM, Andrew MacLeod <amacl...@redhat.com> wrote: > I don't have the time I'd like to since I'm running about a month behind > schedule, but I wanted to make the code I've been experimenting with > available a bit before cauldron so we can discuss it both here and in the > upcoming BOF. > > I created a quick overview document, and managed to keep it to 5 pages :-) > Therefore it is far from complete, but it touches all the major things I > think. It is here: > https://gcc.gnu.org/wiki/rearch?action=AttachFile&do=view&target=gccrestructureplan3.0.pdf > > This code is all located on the branch 're-arch2'. Its based off mainline > revision 211758 dated June 17/2014, so its relatively modern (after wide-int > went in). It builds, bootstraps and passes all regressions. > > I'll send the code changes as 2 patches, directly from the branch. Neither > are intended to be proposed for mainline as is, so you don't need to > critique them... Im not looking for a formal review, I know its a mess.. > and there is no changelog. Its really to give you a feel for what it is > and how it works. Before this code is ready to go in, I'll also be > re-porting whatever optimizations/files are converted since there are a > couple of generations of changes, some of which are probably obsolete now. > I've thrown a few comments in, but I primarily want to discuss the general > approach and future direction. > > The first patch is the new code.. The gimple classes and the wrapper classes > that act as smart pointers to the gimple objects, as well as some interface > stuff to tree.[ch] routines gimple needs at the moment. > > The second patch is the rest of the changes which represent a selection of > .h and .c files I converted, plus some unfortunate ripple effects required > in other .c and .h files :-P (more on that later). I fully converted: > tree-into-ssa.[ch] <- seemed like a good test > gimple-expr.[ch] <- lots of gimple utilities > tree-ssa-ccp.c <- lot of constants and expressions > ssa-iterators.h <- core file used by a lot of optimizations > most of gimple.h <- Wanted access to gimple statements to use gimple > classes > > Im travelling Wednesday night, expect to be jetlagged Thurs and have > meetings Friday, but I will try to respond here when I can. I'll be around > throughout cauldron and at the re-arch2 BOF if anyone wants to tackle me to > discuss any of this... good, bad, or indifferent :-).
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 of 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. Richard. > Andrew
