3 ms·

Google doesn't have full-lto either, since binaries are way too big. Thin-lto is vastly less powerful.

• jeffbee 2y ago
  "Vastly" eh? I seem to recall that LLVM ThinLTO has slight regressions compared to GCC LTO on specCPU but on Google's own applications the superior whole-program devirtualization offered only with ThinLTO is a net win.
  • UncleMeat 2y ago
    I'll adjust my phrasing. As a user, building with thin-lto vs full-lto generally produces pretty similar performance in no small part because a huge amount of effort has gone into making the summaries as effective as possible for key performance needs. As a compiler developer, especially when developing static analysis warnings rather than optimization passes, the number of cases where I've run into "this would be viable if we had full-lto" has been pretty high.
• pcwalton 2y ago
  Yeah, I would have liked to see the paper specify whether the LTO they tried is fat LTO or ThinLTO.
• mgaunard 2y ago
  In practice the default ABI on linux x86-64 is still limiting you to binaries that are 4G or thereabout. Not exactly a problem for LTO since any reasonable build machine will have 128GB of ram.