[Perf] Where are the LLVM symbols coming from?

[blyxyas]

When profiling Clippy either with Valgrind or with cargo lintcheck --perf, we can see that Clippy does a lot of use out of LLVM symbols. We need to investigate why is that the case and how can we remediate it.

Using Valgrind (specifically Callgrind), turns out that we are spending a lot of resources on LLVM symbols that cargo check does not spend resources on.

Where are the LLVM calls coming from? I have some theories.

1. We are using a query/function that triggers codegen.
2. Clippy does not actually deactivate codegen (weird)
3. #![feature(rustc_private)] for importing rustc_hir and such automatically imports LLVM and performs some internal LLVM function.

Some time ago I talked about why does Clippy have so many relocations, and how it could be caused by the dynamic linking. Since then I've had a chat with someone that mentioned that LLVM compilation suffers from a lot of relocations, and how that could be the reason.

[blyxyas]

Also, note that currently, libLLVM.so is making the most allocations in the whole proyect. Via profiling allocations using heaptrack we concluded that libLLVM.so allocates more than 170 Kb of RAM!

[blyxyas]

For posterity and other hackers on this issue:
You can use

LD_LIBRARY_PATH="/home/meow/.rustup/toolchains/nightly-2025-02-27-x86_64-unknown-linux-gnu/lib/" CARGO_TARGET_DIR="/tmp/m7" ltrace -f -l libLLVM.so.20.1-rust-1.87.0-nightly /home/meow/git/rust-clippy/target/release/cargo-clippy &> ltraced

To get the specific libLLVM version, you can use ldd target/release/cargo-clippy or LD_DEBUG=files.

Note that the first command will produce a lot of output, like upwards of 350Mb.
I will now proceed to investigate the output.

[profetia]

I tried to b a few LLVM symbols in gdb and they all comes from module inits. Meanwhile libLLVM itself is introduced by librustc_driver. So I wonder if this is really a clippy problem.