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

[Jan Hubicka]

> 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? 
> To quote myself from "http://gcc.gnu.org/projects/tree-profiling.html":

Actually I don't think it is bad to have one nontrivial IPA optimization
while working on implementation of the IPA infrastructure (tought I
would not recomment put too much effort into implementing more
optimizations at this shape of infrastructure or pushing the quality
of analysis of high gimple in IPA too far.

If we do it right, most of IPA optimizers won't care much about the
actual underlying function representation.  There are number of issues
that needs to be resolved with the infrastructural changes and sometimes
it is good to give it a try in practice.  Lets try to get the clones
cgraph interface right now and we can clean up the actual function
clonning and gimple analysis once we are ready for this (I hope that
this will be relatively soon too)

> 
> ==============================================================
> (...) 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 (*)
>  
> 2. Perform interprocedural analyses and optimizations (at least 
>    constant propagation, side-effects analysis, and function cloning
>    and specialization).
> 
> 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!).

Yep, we really need to resolve the issues concerning the link time
optimizations.

While I personally agree with the scheme you outlined (and also
described it in the GCC Summit paper), the requirement of not loading
whole program into memory at once (so relying only on global date while
doing IPA and performing the actual transformations later) actually
brings some stress on the implementation of IPA optimizers (ie
optimizers done after inlining needs to deal with the clones and it is
dificult to iterate optimizations like we commonly do for local
optimizations).  In fact Kenneth already suggested in private mail to
not use this approach and instead load everything in the memory at once
and do kind of iteration on the IPA.  I would like to hear some opinions
here.

It is quite interesting for me to see how the cprop and Kenneth's alias
analysis are impleemnted and see how much dificulty it is to make it fit
this scheme.
> 
> 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).

Hopefully with the new CFG inliner implementation we will get cloning
functions with CFG needed for cprop for free too (in fact following the
approach of implementing IPA optimizations at once after propagation
pass, it might be nice to make the changes while inlining the function)

Honza