This is the mail archive of the
mailing list for the GCC project.
Re: WHOPR bootstrap, when/how?
- From: Diego Novillo <dnovillo at google dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>, Richard Guenther <rguenther at suse dot de>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 8 Apr 2010 09:13:45 -0400
- Subject: Re: WHOPR bootstrap, when/how?
- References: <firstname.lastname@example.org>
On Thu, Apr 8, 2010 at 06:32, Steven Bosscher <email@example.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
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
Additionally, removing the current WHOPR code will not affect that plan.
The first target I would shoot for, however, is to replace -combine with -flto.