Add unstable `-Zllvm-tpde` flag to `rustc_codegen_llvm` by TechnoPorg · Pull Request #164108 · rust-lang/rust

TechnoPorg · 2026-10-10T16:55:07Z

This adds an unstable -Z llvm-tpde flag to rustc to opt into using the TPDE-LLVM codegen backend instead of LLVM itself. It takes several possible values:

Without the flag, rustc_codegen_llvm operates as before.
With -Zllvm-tpde or -Zllvm-tpde=try, it attempts to compile modules with TPDE, but falls back to LLVM if TPDE fails
With -Zllvm-tpde=only, it attempts to compile modules with TPDE, and bails if TPDE fails (this is intended for development purposes)

This PR does not attempt to optimize TPDE's performance in any way. Previous experiments have run basic optimization passes even on -O0, which helped with wall time, or maintained a list of incompatible IR elements which cause the TPDE path to be skipped. I plan on adding those later.

Stats

	`-Zllvm-tpde=only`	`-Zllvm-tpde=try`
UI tests	489 failed / 21873 passed (2.19% failed)	29 failed / 22333 passed (0.13% failed)

Most of the failing UI tests are to do with assembly, sanitizers, SIMD, and other things we already know TPDE doesn't support. I haven't triaged all the failures yet (not sure if this would be a good use of time at this point).

When compiling ripgrep with -Zllvm-tpde=try, I get a 3-4% wall time improvement, but a 17% icount improvement. I'm less confident in my measurement of the latter metric. 12 out of 1113 CGUs have to fall back to LLVM, with the rest using TPDE. All ripgrep unit tests pass.

Blocked on #163731
@rustbot blocked
r? ZuseZ4
An LLM was consulted on how to use perf to measure instruction counts.

rustbot · 2026-10-10T16:55:11Z

This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

This PR modifies bootstrap.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

The rustc-dev-guide subtree was changed. If your future PRs only touch the subtree, consider submitting them directly to rust-lang/rustc-dev-guide, which is where the document is primarily maintained (and has faster CI).

cc @BoxyUwU, @tshepang

rustc_macros::diagnostics was changed

cc @TaKO8Ki, @JonathanBrouwer

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

TechnoPorg · 2026-10-10T17:00:35Z

A few notes for the review:

This doesn't currently differentiate between opt levels. Should I make it error out on an opt level greater than 1?
A module failing to compile with TPDE spits out a bunch of messages on stdout, which is very helpful for me, but I'm worried about the potential fallout of people opening issues on rust-lang/rust about known limitations of TPDE. Is this worth being concerned about?
- The logging is not very configurable right now: it's currently always on stdout, and the level "ON" or "OFF" is only able to be set at build time, so I will be sending some patches upstream to improve this.

ZuseZ4 · 2026-10-11T12:45:26Z

Awesome. I'm currently traveling with limited data, but I'll be back Monday evening and have a look afterwards.

ZuseZ4 · 2026-10-13T20:15:32Z

Just a quick high-level pass, I'll look closer at the code Thursday/Friday.

This doesn't currently differentiate between opt levels. Should I make it error out on an opt level greater than 1?

I'd warn on higher levels than 1. It's likely to fail, and even if it succeeds, unlikely to provide a significant speedup. A warning should prevent test users from opening issues about that. That being said, I wouldn't error to not block experimenting, maybe someone might surprise us with positive results.

I'm worried about the potential fallout of people opening issues on rust-lang/rust

We can deal with that when it happens. Experimental nightly features are experimental, and using them incorrectly (=on unsupported features like asm) is expected to cause an ICE or similar. No need to delay or make the first PR bigger just to prevent that, especially if it needs upstream changes; those should go in follow-up PRs. :)

(2.19% failed)

#goals/proposed > ✔ goals#791: Propose a project goal for a TPDE backend @ 💬
Based on some python scripting I predicted a failure rate of <5% when forcing TPDE only, so that's exactly what was expected, nice to get a confirmation.

Can you also add a page under the rustc-dev-guide as part of this PR, mirroring the autodiff/offload side? Mainly listing briefly why we have it, how to enable (trivial), what to expect in the current state, and what features are known to not work?

The 489 failures can be triaged later, but the 29 try failures are more interesting, and few enough that we should try to solve them first. Is it just because of some debug printing, or could it be a corner case where your new LLVMCodegenPM uses some undesired default values that we'd otherwise overwrite?

RalfJung

That's not nearly as invasive in our codegen backend as I was afraid it might be. :)

Still it would probably be good for @nikic to take a good look.

View changes since this review

RalfJung · 2026-10-14T06:53:46Z

+        if sess.opts.unstable_opts.tpde.is_some() {
+            sess.dcx().fatal("-Ztpde is LLVM-specific and not supported by Cranelift");
+        }


So every out-of-tree backend has to remember to check for this? That does not scale.

Isn't that what we're already doing, e.g. with instrument-coverage @RalfJung?

rust/compiler/rustc_codegen_cranelift/src/lib.rs

Line 141 in 8d1a764

if sess.opts.cg.instrument_coverage() != InstrumentCoverage::No {

Imho that's just the small price out-of-tree backends pay? This one should also be a graceful failure since it would turn into a no-op, not a misscompilation.

We can do the frontend ad-hock name-check for llvm ourselves. It feels less maintainable to me, but should work. It's afaik just not what we usually do.

Hm I wasn't involved in reviewing those other flags so I didn't know we already have such checks. I feel like we need a proper way for backends to indicate whether they support certain things that doesn't default to "just ignore the flag".

We could have an enum BackendFeature and then a backend_feature_suppoted method on the codegen backend trait?

Yes, having a central method which based on the requested feature returns any of (supported|ignore|warn|error) sounds good. Backends could then overwrite the features they support, and fall through otherwise.

llvm-args seem to get remapped to cranelift/gcc flags.
instrument-coverage is ignored in gcc, errors in cranelift
-Clto is supported in gcc, error's in cranelift
Then there's the thin_lto_supported option in CodegenBackendInit as the one thing we handle explicitly.
Every other llvm specific flag seems to be unhandled and ignored in both cranelift and gcc.

Either way, I'd prefer not having such unrelated change as part of this PR. @TechnoPorg can you open an issue or directly a PR so that we can move the discussion out of this PR?

Opened #164533 and removed the validation function for now

aengelke

This doesn't currently differentiate between opt levels. Should I make it error out on an opt level greater than 1?

I agree to warn (code might be slower due to more vector operations).

The logging is not very configurable right now: it's currently always on stdout, and the level "ON" or "OFF" is only able to be set at build time, so I will be sending some patches upstream to improve this.

Disable logging for now. We ultimately want to have a custom logging infrastructure in TPDE (essentially a function_ref), which TPDE-LLVM or the tpde-plugin.so configures to redirect errors to LLVMContext diagnostics.

View changes since this review

TechnoPorg · 2026-10-15T12:49:33Z

@rustbot author

(still working on CMake build stuff, hopefully done by the end of my UTC-4 day)

TechnoPorg · 2026-10-25T00:31:20Z

I've been running experiments with crater-at-home to gather data on which common instructions are unsupported by TPDE yet (for which I have opened tpde2/tpde#49 upstream). This gives some interesting numbers on how well TPDE supports building¹ "normal" Rust code. I saw no outright build failures due to TPDE (there were some unrelated issues with nightly features).

-Copt-level=0

Of the top 1000 most downloaded crates, 419 fall back to LLVM.

-Copt-level=1

NOTE: I'm pretty sure I botched the data collection here so I will update this once I've re-run.

Of the top 1000 most downloaded crates, 172 fall back to LLVM.

-Copt-level=3

NOTE: I'm pretty sure I botched the data collection here so I will update this once I've re-run.

Although this isn't a recommended mode of operation, I was curious about numbers. Of the top 300 most downloaded crates, 19 fall back to LLVM.

This is just about building. I haven't tried cargo test, and also haven't run any sort of mass benchmarks ↩

ZuseZ4 · 2026-10-25T01:55:29Z

        std::ptr::null()
    };
+
+    let tpde = TpdeWrapper::get_instance();


get_instance goes through a mutex, which is then dropped at the end of this function, right?

write_output_file should be called by multiple workers, so you'd serialize this section, even if we don't want to use tpde. The Mutex wasn't much of an issue in the original Enzyme version since Enzyme requires fat-lto (and thus a single core) anyway, but I don't think we need it here?

View changes since the review

Once resolved we should also do a perf run, to make sure that we don't affect the llvm codegen backend. I've seen a few surprising regressions in the past.

This should be ready for a perf run now

rustbot · 2026-10-25T22:25:55Z

compiletest directives have been modified. Please add or update docs for the
new or modified directive in src/doc/rustc-dev-guide/.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

TechnoPorg · 2026-10-25T22:45:06Z

CI failure is the same as #164921 (comment) and will hopefully be fixed by #164929.

Something something why I became a Rust developer

rustbot · 2026-10-26T00:03:25Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot assigned ZuseZ4 Oct 10, 2026

This comment has been minimized.

Sign in to view

Kobzol mentioned this pull request Oct 12, 2026

Add bootstrap step to build the TPDE plugin #163731

Merged

ZuseZ4 reviewed Oct 13, 2026

View reviewed changes

Comment thread src/doc/rustc-dev-guide/src/traits/hrtb.md Outdated

ZuseZ4 mentioned this pull request Oct 13, 2026

Add an experimental TPDE compilation option rust-lang/goals#802

Open

RalfJung reviewed Oct 14, 2026

View reviewed changes

Comment thread compiler/rustc_session/src/options.rs Outdated

aengelke reviewed Oct 14, 2026

View reviewed changes

TechnoPorg mentioned this pull request Oct 15, 2026

Write TPDE usage/debugging sections rust-lang/rustc-dev-guide#3051

Open

TechnoPorg force-pushed the unstable-tpde-flag branch from 58db8f6 to 6e64be1 Compare October 15, 2026 01:20

This comment has been minimized.

Sign in to view

aengelke reviewed Oct 15, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_llvm/src/diagnostics.rs Outdated

TechnoPorg changed the title ~~Add unstable -Ztpde flag to rustc_codegen_llvm~~ Add unstable -Zllvm-tpde flag to rustc_codegen_llvm Oct 15, 2026

rustbot removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Oct 15, 2026

This comment has been minimized.

Sign in to view

TechnoPorg force-pushed the unstable-tpde-flag branch from 34d9105 to 0a028c2 Compare October 23, 2026 11:31

This comment has been minimized.

Sign in to view

TechnoPorg mentioned this pull request Oct 24, 2026

TPDE-LLVM: Common failures when compiling Rust code tpde2/tpde#49

Open

ZuseZ4 reviewed Oct 25, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_llvm/src/back/llvm_backend.rs Outdated

rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc labels Oct 25, 2026

TechnoPorg requested a review from ZuseZ4 October 25, 2026 22:27

This comment has been minimized.

Sign in to view

TechnoPorg added 15 commits October 25, 2026 20:03

rustc: parse unstable -Ztpde

5728a12

codegen: bail if -Ztpde is used in unsupported context

bd443ba

llvm: add TPDE FFI

2cd21f8

llvm: wire up TPDE

ef1df27

fix: import Tpde in tests

dcf1063

fix: don't run passes after output streams have been dropped

62d4ebe

Something something why I became a Rust developer

fix: don't bail on unsupported options in try mode

9483fb7

fix: more tweaks to TPDE

1b337d2

fix: code pushed prematurely

f27f50d

chore: remove validate_options_for_backend for now

fea16ed

fix: handle interaction between LTO and TPDE flag

243887e

fix: still build TPDE after setting the build target

0f8e0ff

fix: don't accidentally serialize codegen

5d7ce9e

diag: error on split debuginfo with TPDE backend

87b69e0

test: add UI tests for TPDE

f6f50dc

TechnoPorg force-pushed the unstable-tpde-flag branch from 4168143 to f6f50dc Compare October 26, 2026 00:03

Conversation

TechnoPorg commented Oct 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Stats

Uh oh!

rustbot commented Oct 10, 2026

Uh oh!

This comment has been minimized.

TechnoPorg commented Oct 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

ZuseZ4 commented Oct 11, 2026

Uh oh!

Uh oh!

ZuseZ4 commented Oct 13, 2026

Uh oh!

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Oct 14, 2026

Choose a reason for hiding this comment

Uh oh!

ZuseZ4 Oct 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Oct 18, 2026

Choose a reason for hiding this comment

Uh oh!

ZuseZ4 Oct 18, 2026

Choose a reason for hiding this comment

Uh oh!

TechnoPorg Oct 18, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

aengelke left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Uh oh!

TechnoPorg commented Oct 15, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

TechnoPorg commented Oct 25, 2026

-Copt-level=0

-Copt-level=1

-Copt-level=3

Footnotes

Uh oh!

ZuseZ4 Oct 25, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ZuseZ4 Oct 25, 2026

Choose a reason for hiding this comment

Uh oh!

TechnoPorg Oct 25, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Oct 25, 2026

Uh oh!

This comment has been minimized.

TechnoPorg commented Oct 25, 2026

Uh oh!

TechnoPorg commented Oct 10, 2026 •

edited

Loading

TechnoPorg commented Oct 10, 2026 •

edited

Loading

RalfJung left a comment •

edited by rustbot

Loading

ZuseZ4 Oct 18, 2026 •

edited

Loading

aengelke left a comment •

edited by rustbot

Loading

ZuseZ4 Oct 25, 2026 •

edited by rustbot

Loading