This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: WHOPR bootstrap, when/how?


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.

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


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]