This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: WHOPR bootstrap, when/how?
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
decisions.
> The first target I would shoot for, however, is to replace -combine with -flto.
Indeed.
My first target is to get infrastructure ready to fix the TBAA issues.
Richard.