Skip to content

Conversation

@JonathanBrouwer
Copy link
Contributor

Successful merges:

r? @ghost

Create a similar rollup

lqd and others added 14 commits December 7, 2025 13:33
This flag allows specifying the threshold size for placing static data
in large data sections when using the medium code model on x86-64.

When using -Ccode-model=medium, data smaller than this threshold uses
RIP-relative addressing (32-bit offsets), while larger data uses
absolute 64-bit addressing. This allows the compiler to generate more
efficient code for smaller data while still supporting data larger than
2GB.

This mirrors the -mlarge-data-threshold flag available in GCC and Clang.
The default threshold is 65536 bytes (64KB) if not specified, matching
LLVM's default behavior.
There are a number of instances of `FIXME(f16_f128)` related to target
configuration; either these could use `target_has_reliable_f128`, or the
FIXME is describing such a cfg and is thus redundant (since any
`cfg(target_has_reliable_f*)` needs to be removed before stabilization
anyway).

Switch to using `target_has_reliable_*` where applicable and remove the
redundant FIXMEs.
This FIXME was introduced in 6e2d934 ("Add more `f16` and `f128`
library functions and constants") but I can't actually find my
reasoning. As far as I can tell, LLVM has been lowering `fabs.f128` as
bitwise operations for a while across all targets so there shouldn't be
a problem here.

Thus, apply what is suggested in the FIXME.
…6,f128`

Make it easier to identify which FIXMEs are blocking stabilization of
which type.
…h726

inline constant localized typeck constraint computation

This fixes an oversight in the previous PRs, this constraint is local to a point (and liveness does the rest) and so has a fixed direction.

I wasn't planning on trying to improve the impl for perf, versus computing loan liveness without first unifying the cfg and subset graph, but it's like a 20x improvement for typeck constraints on wg-grammar (-15% end-to-end) for a trivial fix.

r? @jackh726

In general, I want to cleanup these edges to avoid off-by-one errors in constraints at effectful statements and ensure the midpoint-avoidance strategy is sound and works well, in particular with respect to edges that flow backwards from the result into its inputs. But I'd like to start from something that passes all tests and is simpler, because the eventual solution may
1. involve localizing these edges differently than *separate* liveness and typeck lowering passes/approaches, which would need to be lowered at the same time for example. I'm already doing the latter in the loan liveness rewrite as part of creating edges on-demand during traversal, and this new structure would be a better fit to verify, or fix, these subtle edges.
2. also require changes in MIR typeck to track the flow across points more precisely, and I don't know how hard that would be. *Computing* the constraint direction is currently a workaround for that.

Therefore, in a future PR, I'll also remove this computation from the terminator constraints, but I can also do that in this PR if you'd prefer.
…d, r=jackh726

Add -Z large-data-threshold

This flag allows specifying the threshold size for placing static data in large data sections when using the medium code model on x86-64.

When using -Ccode-model=medium, data smaller than this threshold uses RIP-relative addressing (32-bit offsets), while larger data uses absolute 64-bit addressing. This allows the compiler to generate more efficient code for smaller data while still supporting data larger than 2GB.

This mirrors the -mlarge-data-threshold flag available in GCC and Clang. The default threshold is 65536 bytes (64KB) if not specified, matching LLVM's default behavior.
…ivooeo

Rename `HandleCycleError` to `CycleErrorHandling`

In rust-lang#101303, the `handle_cycle_error` field was changed from a macro-generated closure to a macro-selected enum variant. But it was not renamed to reflect the fact that it now holds data, not code.

Renaming the field and its associated enum to `cycle_error_handling: CycleErrorHandling` should make the relevant code less confusing to read.

This PR also moves the enum out of `rustc_query_system::error`, where it was easily confused with diagnostic structs.

There should be no change to compiler behaviour.
update enzyme, includes an extra patch to fix MacOS builds in CI

I updated the submodule under rust-lang/enzyme to match EnzymeAD/enzyme, and added one commit, which based on some testing should fix how we build Enzyme in the MacOS CI. Once this pr landed, we will verify again that CI still works, and afterwards upstream the patch and drop it from our fork. No new test failures.

cc @sgasho

r? @Kobzol
…ertdev

Clean up or resolve cfg-related instances of `FIXME(f16_f128)`

* Replace target-specific config that has a `FIXME` with `cfg(target_has_reliable_f*)`
* Take care of trivial intrinsic-related FIXMEs
* Split `FIXME(f16_f128)` into `FIXME(f16)`, `FIXME(f128)`, or `FIXME(f16,f128)` to more clearly identify what they block

The individual commit messages have more details.
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Jan 23, 2026
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) F-autodiff `#![feature(autodiff)]` S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 23, 2026
@JonathanBrouwer
Copy link
Contributor Author

@bors r+ rollup=never p=5

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 23, 2026

📌 Commit 48b9a6c has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 23, 2026
@rust-bors

This comment has been minimized.

@rust-bors rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 23, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 23, 2026

☀️ Test successful - CI
Approved by: JonathanBrouwer
Duration: 3h 12m 26s
Pushing 5944b12 to main...

@rust-bors rust-bors bot merged commit 5944b12 into rust-lang:main Jan 23, 2026
12 checks passed
@rustbot rustbot added this to the 1.95.0 milestone Jan 23, 2026
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#149639 inline constant localized typeck constraint computation fd213d33467815ec6d18e3d3b9a2931d49dc3b34 (link)
#150780 Add -Z large-data-threshold 4a4863570721980af9d09b92decd9abc11b82f08 (link)
#151520 Rename HandleCycleError to CycleErrorHandling ac8ef4b9df337f2bc09076fb9925a750e461b959 (link)
#151525 update enzyme, includes an extra patch to fix MacOS builds … 56b9adce33808391890295c27c197136c95539ba (link)
#151527 Clean up or resolve cfg-related instances of `FIXME(f16_f12… cb18d2a7b59dae13a15f59c315918a35901269e6 (link)

previous master: 9283d592de

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@github-actions
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 9283d59 (parent) -> 5944b12 (this PR)

Test differences

Show 364 test diffs

Stage 1

  • floats::total_cmp_s_nan::test_f16: [missing] -> pass (J1)
  • [assembly] tests/assembly-llvm/large_data_threshold.rs: [missing] -> pass (J2)

Stage 2

  • floats::total_cmp_s_nan::test_f16: [missing] -> pass (J0)
  • [assembly] tests/assembly-llvm/large_data_threshold.rs: [missing] -> pass (J3)

Additionally, 360 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 5944b12bd4cca78d0c32aa67b501af3e1aefd1a9 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. aarch64-gnu-llvm-20-2: 2688.0s -> 3203.4s (+19.2%)
  2. dist-aarch64-apple: 7605.4s -> 8921.3s (+17.3%)
  3. x86_64-rust-for-linux: 2694.8s -> 3098.9s (+15.0%)
  4. test-various: 6768.6s -> 7608.8s (+12.4%)
  5. aarch64-gnu-llvm-20-1: 3305.6s -> 3712.0s (+12.3%)
  6. x86_64-gnu-tools: 3310.0s -> 3680.3s (+11.2%)
  7. dist-apple-various: 4609.0s -> 4115.5s (-10.7%)
  8. i686-gnu-2: 5317.7s -> 5879.2s (+10.6%)
  9. x86_64-gnu: 7550.0s -> 8330.4s (+10.3%)
  10. x86_64-gnu-gcc: 3713.3s -> 4095.7s (+10.3%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (5944b12): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.3%, secondary -6.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
3.0% [2.3%, 3.8%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.3% [-2.3%, -2.3%] 1
Improvements ✅
(secondary)
-6.7% [-6.7%, -6.7%] 1
All ❌✅ (primary) 1.3% [-2.3%, 3.8%] 3

Cycles

Results (primary 2.0%, secondary -2.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.0% [2.0%, 2.0%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.2% [-2.2%, -2.2%] 1
All ❌✅ (primary) 2.0% [2.0%, 2.0%] 2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 471.36s -> 474.479s (0.66%)
Artifact size: 383.50 MiB -> 383.49 MiB (-0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) F-autodiff `#![feature(autodiff)]` merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants