If LLVM is so slow is anything being done about it?

LLVM Project
43

I spend a lot of my (paid) time building and debugging llc, so I’ve become quite sensitive to compile time. And since I constantly run lit tests, I’m also very sensitive to run time. I work on a fairly beefy linux box (56 cores, 135Gb memory). In day to day use you’d expect two kinds of builds: one with debug, and one with full optimization. I’ve noticed a few things:

  • An optimized build of llc typically takes around 48s (around 13m in user time), whereas a debug (-g) build takes ~9m (249m in user time)!
  • Running optimized lit tests (~56000 tests) takes around 2m (74s user time). Running tests compiled with debug takes ~11m (526m user time).

So the fully optimized build time is fast enough that I really don’t consider doing a build with less optimization. And I would tend to attribute much of the 9x compile time increase for the debug build to wrangling dwarf information, exacerbated by huge STL files. But I’d also credit LLVM with lots (not all) of the ~11x testing speedup. Regardless, my turnaround time for an optimized build/test cycle is around 3 minutes, and around 20 minutes for a debug cycle. So you can imagine I don’t build with debug very often.

FWIW, I think threading is a fine idea, as long as it doesn’t compete with the build system for resources, and it doesn’t impede interprocedural optimization. Sounds like the Modular folks are doing some interesting things here.

All that said, I do think there are things we could do to speed up llc (which is where much of my work is), but there are challenges:

  • its extremely easy to perturb both compile-time and runtime performance (both of which are carefully monitored by the community) when changing backend passes/heuristics to improve some metric,
  • many of those ~56000 lit tests are extremely easy to “break”, because they’re looking for exact, ordered sequences of instructions.

Consequentially its really hard to make interesting changes in the backend. Improving a scheduler but “breaking” 500 brittle test cases seems to be de rigueur for me. The lit tests are great, but they effectively impart a lot of inertia to the existing algorithms and heuristics, and doing things that are just compile-time/performance/test-suite neutral is difficult, much less making actual improvements. And as has been pointed out, not too many people are actually paid to do this :slight_smile: (But it’s fun!)

2 Likes