Skip to content

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Oct 15, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

bjoernager and others added 16 commits September 21, 2025 11:45
Where supported, VSX is a 64x128b register set which encompasses both the floating point and vector registers. In the type tests, xvsqrtdp is used as it is the only two-argument vsx opcode supported by all targets on llvm. If you need to copy a vsx register, the preferred way is "xxlor xt, xa, xa".
Implemented preserves_flags on powerpc by making it do nothing. This prevents having two different ways to mark `cr0` as clobbered. clang and gcc alias `cr0` to `cc`. The gcc inline documentation does not state what this does on powerpc* targets, but inspection of the source shows it is equivalent to condition register field `cr0`, so it should not be added.
Makes it clear that this represents `#[doc = "content"]`, but not `#[doc(hidden)]` (or other uses of the `#[doc(...)]` attribute).
…manieu Stabilise `rotate_left` and `rotate_right` in `[_]` as `const fn` items. Tracking issue: rust-lang#143812 Closes: rust-lang#143812 This PR stabilises the `const_slice_rotate` feature: ```rust impl<T> [T] { pub const fn rotate_left(&mut self, mid: usize); pub const fn rotate_right(&mut self, k: usize); } ``` No blockers or unresolved questions. FCP required. Courtesy of `@okaneco.`
…r=Amanieu Add vsx register support for ppc inline asm, and implement preserves_flag option This should address the last(?) missing pieces of inline asm for ppc: * Explicit VSX register support. ISA 2.06 (POWER7) added a 64x128b register overlay extending the fpr's to 128b, and unifies them with the vmx (altivec) registers. Implementations details within gcc/llvm percolate up, and require using the `x` template modifier. I have updated the inline asm to implicitly include this for vsx arguments which do not specify it. ~~Support for the gcc codegen backend is still a todo.~~ * Implement the `preserves_flags` option. All ABI's, and all ISAs store their flags in `cr`, and the carry bit lives inside `xer`. The other status registers hold sticky bits or control bits which do not affect branch instructions. There is some interest in the e500 (powerpcspe) port. Architecturally, it has a very different FP ISA, and includes a simd extension called SPR (which is not IBM's cell SPE). Notably, it does not have altivec/fpr/vsx registers. It also has an SPE accumulator register which its ABI marks as volatile, but I am not sure if the compiler uses it.
resolve: Use primitives for conditional mutability more consistently No bare `(Ref)Cell`s remain in `rustc_resolve`, only `Cm(Ref)Cell`s checking that nothing is modified during speculative resolution, and `Cache(Ref)Cell` aliases for cells that need to be migrated to mutexes/atomics. cc `@LorrensP-2158466`
…=JonathanBrouwer remove span calls from deprecated attribute checking r? `@JonathanBrouwer`
…ent, r=jdonszelmann Clairify docs for `AttributeKind::DocComment` Makes it clear that this represents `#[doc = "content"]`, but not `#[doc(hidden)]` (or other uses of the `#[doc(...)]` attribute). r? `@jdonszelmann`
Add myself to review rotation I'll try it out for a while, and see if I can keep up with things r? compiler
…nieu Clarify that UB will occur, not can/may in GlobalAlloc docs These doc comments start out very clear by saying the caller "must" or "has to" ensure something, but the end with some form of "otherwise undefined behavior may result" which sounds like it is implementation-defined and seems to conflict with the way the paragraph starts. Consistent phrasing makes it clearer that when the safety precondition is violated, UB is encountered. Some of the phrasing here is a bit awkward to me, I don't think we usually say "the behavior is undefined" `@RalfJung` right? But in either case I'm trying to be surgical in my edit here. r? Amanieu
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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. rollup A PR which is a rollup labels Oct 15, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Oct 15, 2025

📌 Commit ed6077a has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors 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 Oct 15, 2025
@bors
Copy link
Collaborator

bors commented Oct 15, 2025

⌛ Testing commit ed6077a with merge 5413f7d...

@bors
Copy link
Collaborator

bors commented Oct 15, 2025

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 5413f7d to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 15, 2025
@bors bors merged commit 5413f7d into rust-lang:master Oct 15, 2025
12 checks passed
@rustbot rustbot added this to the 1.92.0 milestone Oct 15, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#146841 Stabilise rotate_left and rotate_right in [_] as `con… 52c63eb12acdc63164079f70558912ffdd129f61 (link)
#146949 Add vsx register support for ppc inline asm, and implement … e822168579a3800ab391ad4a1029bdc3f13e9604 (link)
#147539 resolve: Use primitives for conditional mutability more con… e36eb0b63adfa3b8d5e0d9940ab22f680561b3f9 (link)
#147685 remove span calls from deprecated attribute checking 3385a9273903f8b7bc41e5ee05fddda8b9581f61 (link)
#147699 Clairify docs for AttributeKind::DocComment bfac61bc7e6e75253f8e72524c91306e4405c630 (link)
#147706 Add myself to review rotation 49c7de4e64e74906869dc328bf68274997df6865 (link)
#147711 Clarify that UB will occur, not can/may in GlobalAlloc docs ee9d4bf7d0224b2de7f87df5d2043c64f1cb8e5d (link)

previous master: 235a4c083e

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

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 235a4c0 (parent) -> 5413f7d (this PR)

Test differences

Show 2 test diffs

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

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \ test-dashboard 5413f7d39cae07b7b3809973fe201d21960a18aa --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. dist-x86_64-apple: 8216.6s -> 6952.6s (-15.4%)
  2. dist-apple-various: 4526.1s -> 3943.6s (-12.9%)
  3. pr-check-1: 1713.7s -> 1517.4s (-11.5%)
  4. dist-aarch64-msvc: 6154.2s -> 5471.2s (-11.1%)
  5. x86_64-gnu-tools: 3791.1s -> 3392.1s (-10.5%)
  6. dist-aarch64-windows-gnullvm: 4740.0s -> 5207.3s (9.9%)
  7. test-various: 4369.6s -> 4769.4s (9.1%)
  8. i686-gnu-nopt-2: 8977.4s -> 8313.6s (-7.4%)
  9. aarch64-msvc-2: 4818.3s -> 5169.9s (7.3%)
  10. dist-x86_64-freebsd: 5000.6s -> 5329.6s (6.6%)
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 (5413f7d): 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 -4.7%, secondary -0.8%)

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

mean range count
Regressions ❌
(primary)
4.2% [4.2%, 4.2%] 1
Regressions ❌
(secondary)
2.8% [2.8%, 2.8%] 1
Improvements ✅
(primary)
-9.1% [-14.3%, -4.0%] 2
Improvements ✅
(secondary)
-2.6% [-2.9%, -2.3%] 2
All ❌✅ (primary) -4.7% [-14.3%, 4.2%] 3

Cycles

Results (secondary -3.9%)

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

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

Binary size

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

Bootstrap: 474.707s -> 475.31s (0.13%)
Artifact size: 388.17 MiB -> 388.10 MiB (-0.02%)

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

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-meta Area: Issues & PRs about the rust-lang/rust repository itself merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.