Re: [tree-profiling-branch PATCH] Function cloning + IPCP extension (RESUBMISSION)

[Razya Ladelsky <RAZYA at il dot ibm dot com>]

Steven Bosscher <stevenb@suse.de> wrote on 10/10/2004 18:50:14:

> On Sunday 10 October 2004 17:20, Razya Ladelsky wrote:
> > Comments are welcome.
> 
> [ The first part of this is turned into a bit of a rant, as I'm feeling
>   really bad about where you are implementing these optimizations. IMHO
>   the abstraction level is wrong, we are not taking things in the right
>   direction...  Skip to /rant for comments on the actual patch ;-)  ]
> 
> I don't mean to say anything bad about your work, but why do you not
> try to help implementing *proper* IPA, starting with a CFG inliner and
> early global (ie. intraprocedural) optimizations *before* IPA, like
> apparently most compilers do? 

We are trying to help the implementation of "proper" IPA, by first 
starting with 
a simple (the simplest?) flow-insensitive analysis of constant propagation 
using 
the existing infrastructure. This should prove to be very useful, and 
easily portable 
to low-level Gimple/CFG/Tree-SSA etc. This already raised critical issues 
such as 
"how to represent the outcome of IPA?" - for CP we can insert a statement 
to indicate 
that a parameter is known to hold a constant value, but for other analysis 
(value prop,
alias analysis) this does not work.


> To quote myself from "http://gcc.gnu.org/projects/tree-profiling.html":
> 
> ==============================================================
> (...) plans exist for reorganisation of the compiler passes as follows:
> 
> 1. For each SCC in the call graph in reverse topological order
>       do simple intraprocedural optimizations in SSA form
>       (basically, run anything that is cheap and can not
>       create overlapping live ranges, but will improve the
>       results of the next step);
>       collect intraprocedural information necessary for
>       interprocedural data flow analyses;
>       store the function's intermediate representation somewhere (*)

Are you convinced that tree-ssa/flow-sensitive/global intraprocedural is 
necessary?
Most of the benefit we know of can be obtained using scalable 
flow-insensitive analysis.
Your scheme implies that we hold all functions in Tree-ssa form, right?


> 
> 2. Perform interprocedural analyses and optimizations (at least 
>    constant propagation, side-effects analysis, and function cloning
>    and specialization).

Where does the inliner kick in? IPA can open-up new 
opportunities/priorities 
for inlining (it already does so now!). 

> 
> 3. For each SCC in the call graph in reverse topological order 
>       do remaining intraprocedural optimizations;
>       hand over the optimized function to the RTL expanders
>       for finalization and code generation.
> ==============================================================
> 
> (*) Either in memory or in a data base.  And yes I *am* willing to
>     open that discussion again if it turns out that we can do great
>     things with IPA but storing in memory is too expennsive (d'oh!).

IPA (and the inliner) need access to all functions together; the important 

point to decide is the representation in which all functions will be held 
together.

> 
> This means that when we start working on this (most likely before the
> end of this year), we (at SUSE, IBM, or whereever) will have to rewrite
> for the new IPA framework *everything* that you're now sort-of hackishly
> implementing in the existing framework that clearly is unsuitable for
> proper IPA.
> The reason *why* almost everything would have to be redone is because
> your implementation does not work on lowered GIMPLE, and also because
> we'll need to clone function CFGs (ie. not function body trees) or lose
> the CFG for cloned/inlined functions, and reconstruct them later on,
> somehow (but that is not really an option IMO).

AFAWCS, porting our IP/CP from trees to lowered Gimple + CFG seems pretty 
straightforward because it's flow insensitive (and we'll definitely do 
that
as soon as it's available for us!). Cloning function CFGs should be done 
very
similarly to the way they are inlined; in-fact, maybe the inliner should 
first
clone the callee, and then tailor it into the caller.


> 
> This is wasteful.  I would *much* rather have everyone agree on clean
> IPA framework design, and work together on implementing that.
> 
> Don't get me wrong, it is really really cool that y'all want to have 
this
> implemented in GCC.  So do I.  It is also great that you're 
experimenting
> with these algorithms, demonstrating that it can be done for GCC.
> 
> But what is happening right now is making things only more difficult in
> the long run.  We already have this lame excuse for IPA with the "Inter
> Module" C front end hack that will have to be redone if GCC is ever 
going
> to support real IPA. 
> And IMHO we do not need more obfuscated pseudo-IPA/IPO implementations
> like that; not now that we have the opportunity to do it properly with
> the cgraph module and low-GIMPLE which is relatively easy to serialize
> and dump to a data base.
> 
> If only these reasons mattered, I'd really rather not have this patch
> in CVS.  Perhaps other people have a different opinion, of course ;-)
> 

> Thanks,
> 
> Gr.
> Steven
> 
> 

Thanks, 
Razya