On Thu, 8 Apr 2010, Diego Novillo wrote: > On Thu, Apr 8, 2010 at 06:32, Steven Bosscher <stevenb....@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.
