Re: lto

[Jan Hubicka <jh at suse dot cz>]

> Your idea seems fine to me.  Unless I'm not understanding you 
> completely, it does not really conflict with what we're trying to do in 
> whopr.
> 
> The main goal of whopr is to support transformations that can be 
> expressed in terms of a local generation phase, a global analysis that 
> decides an optimization plan and then a final transformation phase that 
> applies that plan.
> 
> The first and last steps are meant to run in parallel.  The distribution 
> of tasks can be done outside of the compiler (ideally, via 'make -j' or 
> distcc or what have you).
> 
> Certainly, not every IPA transformation can fit this plan, anything that 
> needs iterating or has cascading effects may not apply.  But for the 
> main IPA transformations (notably inlining), this structure produces 
> good results.  If I understand Jan correctly, this is what he means by 
> 'Big IPA' in his last message.

Yes, what I mant by Big ipa is precisely IPA organized by local
analysis/global execution and local modification passes as described in
whopr.  The original callgraph code was organized this way (it is
described in 2003 gccsummit paper) since I hoped at that time the IL
writting to be possible soon after tree-SSA merge and watned the code to
be ready for this.  The experience with this organization of IPA was
that while inlining/constant propagation and analysis fit well nicely,
some other cases didn't introducing pass ordering difficulties. This is
why I think combination of both approaches might lead to easier to
maintain and probably more effective IPA.

In general for good performance we want to push as much work as possible
into the compilation stage instead of linktime stage.  We will probably
want to do some of IPA optimization (mostly targetted to reduction of
code size) at that stage too, early inlining was one of cases
particularly meant for that.
> 
> So, if you build the mechanisms to read/write LTO information from 
> files, and the ability to load things on demand, that's great.  We do 
> not need to arrive to the final solution in one step, incremental little 
> victories are a lot more important.  In fact, I very strongly suggest 
> doing this incrementally.

Looks like all the possible scenarios have the first few things in
common: ie be able to read functions one by one from object files,
reorganize IPA passes to the three parts and be able to serialize the
summaries.

Honza
> 
> The only thing that I'd like to watch out for is to keep the 
> implementation flexible so that we don't need to re-implement many 
> things from scratch when we are ready to extend the system.
> 
> 
> Thanks.  Diego.