[epage]

> for a large C codebase like the Linux kernel, we're spending way more time in the front-end (clang) than the backend (llvm). This was surprising based on rustc's experience with llvm.

rustc sends large, generally unoptimized chunks to llvm, compared to clang. In Rust, the translation unit is at the crate level, causing llvm to do more analysis. MIR is also still relatively new and I think there is still work to be done doing optimizations in it to get less data sent to llvm.

[ndesaulniers]

Clang doesn't do optimizations though. It generates llvm via a simple tree walk.

[fluffything]

What's big in C or C++ translation units are header files, but since these mainly contain declarations, and declarations do not require code generation, they don't create any work for the compiler backend.

Rust translation units do not have the header file problem (so the frontend does less work), and they are also much larger in terms of definitions, often spawning multiple files, so there is more for the backend to do per translation unit.

The consequence is that Rust spends more time on LLVM relatively speaking than C and C++.

The solution to this problem in Rust is naively simple: write smaller translation units.

Rust programmers just want to structure their code however their want, and still have good compile-times. Which is kind of the opposite of how C and C++ programmers typically structure their code in the largests projects, because they value faster compile-times over that kind of "ergonomics"/code organization.

[ndesaulniers]

Ah. Same problem with static inline functions defined in headers in the kernel. They may not end up generating code, but clang doesn't know that and will still generate llvm for the backend to determine is dead, after clang has already done lots of work performing semantic analysis on it.

Orthogonal to your point:

Also, aggressively marking functions __attribute__((always_inline)) we found was blowing up compile times (reoptimizing the same code again and again).

Finally, expansions of function like macros containing GNU C statement expressions could cause the preprocessed source to bloat very quickly (megabytes of input, IIRC).

[fluffything]

Rust doesn't have the "static in header" problem, but it does have the "always inline" and "macros" problem.

The "always inline" problem is smaller in Rust, because it does Thin LTO by default, compiles partially to bit-code, that can be partially inlined if necessary, etc. So essentially the Rust toolchain is a bit better at inlining when its profitable than C and C++ toolchains "by default" (you can tune C and C++ toolchains like clang to be as good as Rust).

In C and C++, macros are generally frowned upon, not because of this compile-time issues, but rather because they are dangerous, tricky, non-hygienic, powerful usage requires complex patterns, their interaction with header files and PCHs, etc.

Rust macros are awesome, super useful, widely used, etc. So people end up using them a lot, and this is by design, not a flaw of the language. This ends up resulting in a lot of duplicated code being expanded, and that leads to the problem that you mention, but much worse, because there are just many more macros in Rust.

This kind of applies to templates / traits as well. There are many C++ that don't write templates, but all Rust programmers use generics because they are great. Rust can pre-compile generics, so the cost of this is not as bad as for C++ where the same generic might be instantiated by multiple TUs. But still, just by the fact that they are more widely used, the size of the problem grows.