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. The first target I would shoot for, however, is to replace -combine with -flto. Diego.
