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

I did some checking with clang -ftime-trace building LLVM in release mode (so with optimizations). This generally breaks the build into clang frontend + clang codegen (creating LLVM IR) + IR optimizations + LLVM codegen (emitting machine code). The way this breaks down varies from file to file, but the general rule of thumb is that clang frontend is the most time-consuming followed by IR optimizations, LLVM codegen, and clang codegen usually being tiny. I’d say the frontend taking 50-60% of the time is close to average, with IR optimizations usually 20-30% of time. However, there are some files where IR optimizations take about 50% of the time (X86ISelLowering.cpp and PassBuilder.cpp are some bad offenders here).

Granted, this is a test on a clean build from a cold cache of a C++ code. Given the prevalence of templates in C++, and the C/C++ way of #include’ing code for dependencies, it’s not surprising that compiling should be relatively time-heavy in the front-end. I think a lot of the projects complaining about LLVM speed are focused more on making the compile-edit-recompile cycle times very fast, and generally in languages where you don’t have to include MB’s of duplicated code to rewrite, so the metrics from a C/C++ compiler aren’t necessarily the most useful to them.

3 Likes