Bridging the Gap Between Rust's Theoretical IR Advantages and Real-World Performance

[gaowujie2004]

Bridging the Gap Between Rust's Theoretical IR Advantages and Real-World Performance

Hi everyone,

I’ve been diving deep into the LLVM IR generated by rustc and comparing it with the output from Clang for equivalent C/C++ code. This has led me to a question regarding the current state of Rust's optimization pipeline.

The Premise: The "Information Dividend"

In theory, Rust generates LLVM IR that contains significantly richer semantic information than C/C++. This should, logically, allow the backend to perform more aggressive optimizations:

1. Aliasing Guarantees: Rust's &mut T maps to noalias, and &T maps to readonly. This provides stronger guarantees than C's restrict keyword (which is rarely used correctly) and should unlock aggressive load/store reordering, LICM, and auto-vectorization.
2. Type Constraints: References are guaranteed nonnull, and enums/booleans have strict value ranges (noundef, !range metadata).
3. Immutability: Shared references allow for confident Constant Subexpression Elimination (CSE).

The Reality

Despite these theoretical advantages, real-world benchmarks often show Rust performing on par with, or sometimes slightly trailing (~1-5%), highly tuned C/C++. It seems that this "information dividend" isn't fully capitalizing into runtime performance yet.

Hypotheses on Obstacles

Based on my analysis of the generated assembly and IR, I’ve hypothesized a few reasons for this. I’d love to know if these assessments align with the compiler team’s observations:

1. LLVM's "C-Bias" in Heuristics The LLVM backend has been tuned for decades to recognize C/C++ code patterns. Rust generated IR, while valid, often produces patterns (e.g., heavy Option/Result unwrapping, complex closure expansions in iterators) that may not trigger existing optimization heuristics designed for C-style loops and branches.

2. Implicit memcpy & Stack Inefficiency Due to Rust's Move semantics and the current implementation of Box::new, Release builds still exhibit a significant amount of memcpy instructions and heavy stack usage. While LLVM's MemCpyOpt exists, it seems insufficient to eliminate copies across function boundaries or complex control flows, leading to unnecessary memory traffic.

3. Bounds Checking Overhead While iterators eliminate many checks, index-based access still incurs overhead. C compilers often generate tighter code by leveraging Undefined Behavior (assuming no OOB access), a luxury Rust cannot afford by default.

---

Questions for the Team

To understand the roadmap for unlocking Rust's full potential, I am curious about the following directions:

Q1: MIR Optimizations vs. LLVM Upstreaming Is the long-term strategy to rely more on MIR Optimizations (like Destination Propagation) to "clean up" the code before it reaches LLVM, or is the focus shifting towards upstreaming Rust-specific optimization passes (or tuning heuristics) directly into LLVM?

Q2: The "Memcpy" Problem Regarding excessive stack copies (and Box::new stack overflows): Is a language-level "Placement New" feature still being actively explored, or is the consensus to solve this entirely through compiler smarts like improved NRVO and Destination Propagation?

Q3: Rust-Specific LLVM Tuning Are there active efforts to collaborate with the LLVM team to introduce heuristics specifically for Rust IR patterns? For example, better handling of the complex branch/switch structures often generated by match expressions on enums.

Q4: Code Bloat & Polymorphization What is the current status of Polymorphization? Is it viewed as the primary solution to Rust's binary size bloat and Instruction Cache pressure caused by aggressive monomorphization?

I would greatly appreciate any insights from the compiler team or contributors working on these fronts.

Thanks!

[bjorn3]

The old polymorphization implenentation got removed per

Delete current polymorphization implementation

[Noratrieb]

Please don't use large language models to write your posts. It creates a large asymmetry between the time put in by you and the time expected from others.

[scottmcm]

@gaowujie2004

Despite these theoretical advantages, real-world benchmarks often show Rust performing on par with, or sometimes slightly trailing (~1-5%), highly tuned C/C++.

Do you have an example? Speaking in the abstract often goes less well than just looking specifically at one particular comparison where there can be a specific thing to address.

@gaowujie2004

Is the long-term strategy to rely more on MIR Optimizations (like Destination Propagation) to "clean up" the code before it reaches LLVM, or is the focus shifting towards upstreaming Rust-specific optimization passes (or tuning heuristics) directly into LLVM?

MIR is a poor IR for writing complex optimizations, so anything more than relatively-simple ones are best done in LLVM (or potentially in a hypotheitical "LIR" Low-level IR).