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

[Steven Bosscher <stevenb@suse.de>]

On Sunday 10 October 2004 22:59, Jan Hubicka wrote:
> 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 my mental model, inlining and cloning would be one of the
last optimizations to do on the call graph.  Wouldn't it be a
simple matter of adding the clones to the call graph and moving
on as if it is a normal compilation?  At least you would not
actually do any IPA on clones and functions after inlining.
That would  require re-analyzing the function to get the global
data right, wouldn't it?



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

Can you show some pseudo-algorithm of how this would work?


>  I would like to hear some opinions
> here.

Hmm, obviously it depends on how much we can improve on memory
efficiency, there is obvioulsy a lot of room for improvements
there if we could move to saner data structures.  Everyone knows
we're a *little* memory wasteful right now ;-)

But even then, I wonder if you could take the source of a very
large code base (say, GCC itself, or the linux kernel), and do
link time whole program optimizations on it if you have to keep
everything in memory.

And iterating (or perhaps worklist based?) IPA doesn't sound very
attractive either.  I suppose you could offer it as an option at
some very high optimization level, but does it really pay off in
general to do IPA so aggressively?  Is the benefit large enough to
justify a complicated and probably compile time expensive framework
like that?

In any case, we'll be stuck on doing everything in-memory at first
anyway, so we'll have the opportunity to experiment a bit, and that
will be interesting.  Of course, making pre-inlining optimizations
possible is the most important thing for now...

Gr.
Steven