Adding additional context:
Compile times are important; if you want developers to use Clang (which helps their code bases support Clang as a compiler), having it be faster than the competition is important to winning developer mindshare. We’ve had multiple complaints about this from Linux kernel developers.
Since 2020, Clang has been slower than the competition when compiling the Linux kernel by 7% to 28%.
Here’s a fresh profile of a Linux kernel build with clang.
(Instructions for reproducing these measurements)
As you can see, the entirety of kernel build times are dominated by Clang. Not the linker, not other host utilities invoked during the build, not LLVM optimization passes. Just Clang (the front end).
We’ve made tiny progress recently putting a dent in these with ⚙ D131532 [Sema] Avoid isNullPointerConstant invocation which shaved off ~2.1% of cycles, but there’s a lot more we can be doing.
(Independently of algorithmic optimizations, I’m playing with staticly linking clang against musl+llvm-libc, then building it with LTO, PGO, and BOLT. I’m also looking into how we can measure+automate something like iwyu for the kernel).
https://reviews.llvm.org/D20401 introduced a major performance regression for kernel builds, and I wasn’t the only one to pinpoint that commit as being problematic.
There’s obviously more than just getFileIDLocal that could use some attention, so posting profiles in case others are interested in “Make Clang Fast Again” (MCFA).