WHOPR bootstrap, when/how?

Richard Guenther rguenther@suse.de
Thu Apr 8 14:21:00 GMT 2010

On Thu, 8 Apr 2010, Diego Novillo wrote:

> On Thu, Apr 8, 2010 at 06:32, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> > I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled.
> > Not sure what happened, other than that my machine ran out of memory.
> > I guess this is kind-of expected, but it made me wondering how much
> > work, and what exactly, remains to be done before bootstrapping with
> > WHOPR enabled is possible. Is this even a goal?
> It was.  Unfortunately,work on it stopped last year and it is unlikely
> that I will be assigned to this again.  I still have some personal
> interest on the feature, but given time restrictions, we should make
> contingency plans.
> Perhaps the easiest option is to remove the feature.  WHOPR does not
> represent a lot of code over the basic LTO framework, so this should
> be relatively easy and non-intrusive.
> If we do keep it, my expectation was to convert WHOPR into a
> profile-guided feature, much like what LIPO does.  Instead of trying
> to statically decide what TUs to compile together, we generate gimple
> bytecode for all TUs, then link normally (without combining them) and
> run the binary with profile generation enabled.
> During the second compilation, we use the profile generated to decide
> what TUs to link together.  This avoids the complexity we currently
> have with WHOPR, which needs to re-exec itself and make static
> decisions.
> Additionally, removing the current WHOPR code will not affect that plan.

I think we're going to fix WHOPR, not remove it.  The overall idea is
sane and we can still use profile-feedback to drive its partitioning

> The first target I would shoot for, however, is to replace -combine with -flto.


My first target is to get infrastructure ready to fix the TBAA issues.


More information about the Gcc mailing list