T Compiler Meeting Agenda 2025 07 10

T-compiler Meeting Agenda 2025-07-10

Announcements

  • Hey @T-compiler/meeting! Do we want to schedule a P-high issue review meeting?
  • Reminder: if you see a PR/issue that seems like there might be legal implications due to copyright/IP/etc, please let us know (or at least message @davidtwco or @Wesley Wiser so we can pass it along).

Other WG meetings

MCPs/FCPs

Backport nominations

T-compiler beta / T-compiler stable

  • :beta: “Update LLVM submodule” rust#143126
    • Authored by @dianqk (amazing work!)
    • Fixes a slew of micompilation issues: #140686, #141913, #142752, #143399
    • Voting Zulip topic, positive unanimously
  • :beta: “Do not unify borrowed locals in CopyProp.” rust#143509
    • Authored by cjgillot
    • Fixes #143491 (a probably p-high unsoundness)
    • Voting Zulip topic, positive unanimously
  • No stable nominations for T-compiler this time.

T-types beta / T-types stable

  • No beta nominations for T-types this time.
  • No stable nominations for T-types this time.

PRs S-waiting-on-team

T-compiler

Issues of Note

Short Summary

P-critical

T-compiler

  • No P-critical issues for T-compiler this time.

T-types

  • No P-critical issues for T-types this time.

P-high regressions

P-high beta regressions

  • No P-high beta regressions this time.

Unassigned P-high nightly regressions

  • No unassigned P-high nightly regressions this time.

Performance logs

triage logs for 2025-07-07

Busy week. Results are dominated by changes that trade some wins for some losses in small incremental scenarios. We also had a lot of noise and spurious small changes on various PRs. Some regressions come from perf related work where we expect to get some wins back later.

Triage done by @panstromek. Revision range: ad3b7257..0d11be5a

Summary:

Note: We switched to a new benchmark machine at the begining of the period. We show summary based on slightly adjusted range 6988a8fe..8df4a58a to avoid misleading comparisons from different machines.

(instructions:u)meanrangecount
Regressions (primary)1.1%[0.2%, 4.3%]128
Regressions (secondary)1.0%[0.2%, 3.9%]84
Improvements (primary)-3.5%[-7.2%, -0.2%]48
Improvements (secondary)-5.1%[-42.6%, -0.2%]68
All (primary)-0.2%[-7.2%, 4.3%]176

3 Regressions, 3 Improvements, 11 Mixed; 6 of them in rollups 44 artifact comparisons made in total

Regressions

Rollup of 8 pull requests #143267 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)0.2%[0.2%, 0.2%]1
Regressions (secondary)0.3%[0.1%, 1.1%]18
Improvements (primary)--0
Improvements (secondary)--0
All (primary)0.2%[0.2%, 0.2%]1

The regressed benchmarks are small and fairly aritifical. Some of the results look like noise and returned to previous state. I don’t think this is worth investigating more.

Add new self-profiling event to cheaply aggregate query cache hit counts #142978 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)0.3%[0.1%, 0.4%]17
Regressions (secondary)0.4%[0.3%, 0.5%]7
Improvements (primary)--0
Improvements (secondary)--0
All (primary)0.3%[0.1%, 0.4%]17

Seems like overhead of the measurement. Pinged the author, but seems like we can’t do much about that.

Do not unify borrowed locals in CopyProp. #143509 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)0.2%[0.1%, 0.3%]21
Regressions (secondary)0.4%[0.1%, 1.1%]38
Improvements (primary)-0.4%[-0.4%, -0.4%]2
Improvements (secondary)--0
All (primary)0.1%[-0.4%, 0.3%]23

Soundness fix in an mir-opt pass. Posted a comment to make sure these are expected.

Improvements

Weekly cargo update #142857 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)--0
Regressions (secondary)--0
Improvements (primary)-2.9%[-2.9%, -2.9%]1
Improvements (secondary)--0
All (primary)-2.9%[-2.9%, -2.9%]1

Allow enum and union literals to also create SSA values #138759 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)--0
Regressions (secondary)--0
Improvements (primary)-0.3%[-0.4%, -0.2%]6
Improvements (secondary)-0.3%[-0.5%, -0.3%]3
All (primary)-0.3%[-0.4%, -0.2%]6

Canonicalize input ty/ct infer/placeholder in the root universe #142732 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)--0
Regressions (secondary)0.3%[0.3%, 0.3%]1
Improvements (primary)--0
Improvements (secondary)-1.0%[-1.8%, -0.3%]13
All (primary)--0

Mixed

Introduce ByteSymbol #141875 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)--0
Regressions (secondary)1.7%[1.4%, 2.1%]5
Improvements (primary)-1.5%[-6.4%, -0.2%]264
Improvements (secondary)-1.9%[-6.1%, -0.3%]298
All (primary)-1.5%[-6.4%, -0.2%]264

First PR benchmarked on new machine, these changes are not real as they compare results from different machines. Pre-merge results are much less significant.

Start moving wf checking away from HIR #142030 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)--0
Regressions (secondary)0.4%[0.3%, 0.6%]3
Improvements (primary)-0.4%[-0.4%, -0.4%]2
Improvements (secondary)-0.5%[-1.1%, -0.3%]8
All (primary)-0.4%[-0.4%, -0.4%]2

Marked as triaged by author with comment: Improvements outweigh the regressions. And measured time is improved on the only benchmark that regressed instructions.

Rollup of 11 pull requests #143338 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)0.4%[0.3%, 0.4%]2
Regressions (secondary)0.2%[0.2%, 0.4%]5
Improvements (primary)--0
Improvements (secondary)-0.1%[-0.1%, -0.1%]1
All (primary)0.4%[0.3%, 0.4%]2

Most of the regressions are probably safe to ignore (small, secondary or noise). The biggest one is in cargo, where the regression is in LLVM, which indicates something probably changed in relation to optmizations or codegen scheduling. Most of the code changes here seem unrelated, though. I suspect it could be one of the standard library changes in first three PRs.

This seems to have returned back to previous state with a little improvement on top in https://github.com/rust-lang/rust/pull/143509, detailed results show inverse numbers on the same LLVM-related queries, but since that PR changed mir optimizations, it probably has some effect on that, too.

Rollup of 6 pull requests #143363 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)3.0%[3.0%, 3.0%]1
Regressions (secondary)--0
Improvements (primary)-0.3%[-0.5%, -0.2%]11
Improvements (secondary)-0.4%[-1.1%, -0.2%]14
All (primary)-0.0%[-0.5%, 3.0%]12

Already triaged by @lqd: The usual clap-derive noise, and it returned to normal on the next merge.

Rollup of 5 pull requests #143390 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)3.0%[3.0%, 3.0%]1
Regressions (secondary)--0
Improvements (primary)--0
Improvements (secondary)-0.7%[-1.2%, -0.2%]8
All (primary)3.0%[3.0%, 3.0%]1

Triaged by @Kobzol: clap_derive bimodal noise.

MIR inliner maintains unused var_debug_info #142890 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)1.8%[1.8%, 1.8%]1
Regressions (secondary)--0
Improvements (primary)-2.9%[-2.9%, -2.9%]1
Improvements (secondary)--0
All (primary)-0.6%[-2.9%, 1.8%]2

clap_derive improvement is bimodal noise. ripgrep regression doesn’t make sense to me. We either do less work or the same amount of work here (not sure which debuginfo option we use for this benchmark). Wall time has no relevant changes, though, so I assume it’s spurious.

Avoid depending on forever-red DepNode when encoding metadata. #143247 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)0.6%[0.2%, 2.0%]61
Regressions (secondary)1.1%[0.2%, 2.1%]21
Improvements (primary)--0
Improvements (secondary)-25.5%[-42.6%, -16.4%]6
All (primary)0.6%[0.2%, 2.0%]61

Part of recent metadata related perf work. Regressions are expected and will be investigated in a followup.

Make metadata a workproduct and reuse it #114669 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)1.0%[0.2%, 2.2%]76
Regressions (secondary)0.8%[0.3%, 1.7%]23
Improvements (primary)-4.3%[-7.5%, -1.1%]45
Improvements (secondary)-4.9%[-11.6%, -0.5%]36
All (primary)-1.0%[-7.5%, 2.2%]121

Regressions outweigh improvements. Note that lot of the regressions are on very small benchmarks, so the negative effects are somewhat exaggerated. Based on PR description, this change also targets worspace use case that is not represented well in our benchmarks.

Remove Symbol from Named variant of BoundRegionKind/LateParamRegionKind #139598 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)0.5%[0.1%, 3.2%]13
Regressions (secondary)0.4%[0.1%, 0.6%]23
Improvements (primary)--0
Improvements (secondary)-0.4%[-0.5%, -0.1%]7
All (primary)0.5%[0.1%, 3.2%]13

Pre merge results don’t match post merge results. Most regressions are in doc benchmarks, impact seems quite low. I left a comment asking for next steps.

Rollup of 6 pull requests #143507 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)--0
Regressions (secondary)0.2%[0.2%, 0.3%]2
Improvements (primary)--0
Improvements (secondary)-0.7%[-1.4%, -0.2%]8
All (primary)--0

Improvements outweigh regressions, changes are tiny. coercions regressions seems to be noise. I don’t think this is worth digging into.

Rollup of 6 pull requests #143521 (Comparison Link)

(instructions:u)meanrangecount
Regressions (primary)0.2%[0.2%, 0.2%]1
Regressions (secondary)0.3%[0.2%, 0.3%]2
Improvements (primary)--0
Improvements (secondary)-1.2%[-1.9%, -0.0%]9
All (primary)0.2%[0.2%, 0.2%]1

coercions regressions seems to be noise, looks like a new bimodailty. Other changes are tiny, I don’t think this is worth investigating.

Nominated Issues

T-compiler

  • No I-compiler-nominated issues this time.

RFC

  • No I-compiler-nominated RFCs this time.

Oldest PRs waiting for review

T-compiler

  • TODO

Next meeting’s agenda draft: hackmd link