Skip to content

slice.get(i) should use a slice projection in MIR, like slice[i] does #139118

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 1, 2025

Conversation

scottmcm
Copy link
Member

slice[i] is built-in magic, so ends up being quite different from slice.get(i) in MIR, even though they're both doing nearly identical operations -- checking the length of the slice then getting a ref/ptr to the element if it's in-bounds.

This PR adds a slice_get_unchecked intrinsic for impl SliceIndex for usize to use to fix that, so it no longer needs to do a bunch of lines of pointer math and instead just gets the obvious single statement. (This is not used for the range versions, since slice[i..] and slice[..k] can't use the mir Slice projection as they're using fenceposts, not indices.)

I originally tried to do this with some kind of GVN pattern, but realized that I'm pretty sure it's not legal to optimize BinOp::Offset to PlaceElem::Index without an extremely complicated condition. Basically, the problem is that the Index projection on a dereferenced slice pointer cares about the metadata, since it's UB to PlaceElem::Index outside the range described by the metadata. But then you cast the fat pointer to a thin pointer then offset it, that ignores the slice length metadata, so it's possible to write things that are legal with Offset but would be UB if translated in the obvious way to Index. Checking (or even determining) the necessary conditions for that would be complicated and error-prone, whereas this intrinsic-based approach is quite straight-forward.

Zero backend changes, because it just lowers to MIR, so it's already supported naturally by CTFE/Miri/cg_llvm/cg_clif.

@rustbot
Copy link
Collaborator

rustbot commented Mar 29, 2025

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added 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 Mar 29, 2025
@rustbot
Copy link
Collaborator

rustbot commented Mar 29, 2025

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Comment on lines 30 to 36
bb2: {
StorageDead(_3);
StorageLive(_7);
StorageLive(_5);
_5 = &raw mut (*_1);
StorageLive(_6);
_6 = copy _5 as *mut u32 (PtrToPtr);
_7 = Offset(copy _6, copy _2);
StorageDead(_6);
StorageDead(_5);
_8 = &mut (*_7);
_0 = Option::<&mut u32>::Some(copy _8);
StorageDead(_7);
_5 = &mut (*_1)[_2];
_0 = Option::<&mut u32>::Some(copy _5);
goto -> bb3;
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

annot: this pre-codegen test is the clearest demonstration of what the PR does.

index: usize,
) -> ItemPtr;

pub trait SliceGetUnchecked<T> {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A brief doc comment would be good, it is a public trait after all. (I am surprised CI does not complain.)

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 1, 2025
@rustbot
Copy link
Collaborator

rustbot commented Apr 1, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@scottmcm scottmcm force-pushed the slice-get-unchecked-intrinsic branch from 4cf8aa1 to bb5dd9b Compare April 6, 2025 04:10
@scottmcm
Copy link
Member Author

scottmcm commented Apr 6, 2025

Ok, updated:

  1. Redid the comment to talk about the projection primarily, just mentioning MIR as an aside that backends don't need to implement it.

  2. Moved the trait to a private module to emphasize that it's not for public use, gave it some comments, and redid it to be more general so it can also replace the AggregateRawPtr trait.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 6, 2025
@rust-log-analyzer

This comment has been minimized.

@scottmcm scottmcm force-pushed the slice-get-unchecked-intrinsic branch from bb5dd9b to 5d9cc7a Compare April 6, 2025 04:20
@rust-log-analyzer

This comment has been minimized.

@scottmcm scottmcm closed this Apr 6, 2025
@scottmcm scottmcm reopened this Apr 6, 2025
@rust-log-analyzer

This comment has been minimized.

@scottmcm scottmcm force-pushed the slice-get-unchecked-intrinsic branch from 5d9cc7a to 938fe84 Compare April 6, 2025 07:19
@rust-log-analyzer

This comment has been minimized.

@workingjubilee
Copy link
Member

?

The Far Side's "cow tools" comic but it is GNU's gnu instead of a cow and also the tools are scrolling prompts emitted by Autotools... they're gnu tools, get it?

@workingjubilee
Copy link
Member

uhh, sorry for not noticing this earlier, can you clarify its status?

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 1, 2025
@RalfJung
Copy link
Member

RalfJung commented May 1, 2025

Looks like we got really unlucky in the linux-futex test... and/or the probabilities shifted since this affects a lot of MIR.

Chances are if you rebase and try again, it'll work this time. I can play around with the numbers in that test later.

@scottmcm scottmcm force-pushed the slice-get-unchecked-intrinsic branch from 938fe84 to 8e85afd Compare May 1, 2025 17:55
@scottmcm
Copy link
Member Author

scottmcm commented May 1, 2025

Thanks, Ralf! Looks like it worked out with just the rebase, as you predicted.

@rustbot ready

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label May 30, 2025
@workingjubilee
Copy link
Member

Sorry, I noticed while scanning the queue that this is not rollup=never... it was not run through perf, it seems? My fault. The odds this does not affect perf significantly seem... small. Will reapprove assuming it's perf-neutral.

@bors r-

@bors2 try @rust-timer queue

@rust-timer

This comment has been minimized.

@rust-bors
Copy link

rust-bors bot commented May 30, 2025

⌛ Trying commit 4668124 with merge 462bbcc

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 30, 2025
rust-bors bot added a commit that referenced this pull request May 30, 2025
`slice.get(i)` should use a slice projection in MIR, like `slice[i]` does

`slice[i]` is built-in magic, so ends up being quite different from `slice.get(i)` in MIR, even though they're both doing nearly identical operations -- checking the length of the slice then getting a ref/ptr to the element if it's in-bounds.

This PR adds a `slice_get_unchecked` intrinsic for `impl SliceIndex for usize` to use to fix that, so it no longer needs to do a bunch of lines of pointer math and instead just gets the obvious single statement.  (This is *not* used for the range versions, since `slice[i..]` and `slice[..k]` can't use the mir Slice projection as they're using fenceposts, not indices.)

I originally tried to do this with some kind of GVN pattern, but realized that I'm pretty sure it's not legal to optimize `BinOp::Offset` to `PlaceElem::Index` without an extremely complicated condition.  Basically, the problem is that the `Index` projection on a dereferenced slice pointer *cares about the metadata*, since it's UB to `PlaceElem::Index` outside the range described by the metadata.  But then you cast the fat pointer to a thin pointer then offset it, that *ignores* the slice length metadata, so it's possible to write things that are legal with `Offset` but would be UB if translated in the obvious way to `Index`.  Checking (or even determining) the necessary conditions for that would be complicated and error-prone, whereas this intrinsic-based approach is quite straight-forward.

Zero backend changes, because it just lowers to MIR, so it's already supported naturally by CTFE/Miri/cg_llvm/cg_clif.
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label May 30, 2025
@rust-bors
Copy link

rust-bors bot commented May 30, 2025

☀️ Try build successful

  • CI
    Build commit: 462bbcc (462bbcc7f1ef36956f33c903203abed871d66de3)

@rust-timer

This comment has been minimized.

@workingjubilee workingjubilee added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 31, 2025
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (462bbcc): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
0.6% [0.6%, 0.6%] 1
Regressions ❌
(secondary)
0.2% [0.2%, 0.2%] 1
Improvements ✅
(primary)
-1.0% [-1.0%, -1.0%] 1
Improvements ✅
(secondary)
-0.5% [-0.5%, -0.5%] 1
All ❌✅ (primary) -0.2% [-1.0%, 0.6%] 2

Max RSS (memory usage)

Results (primary -0.3%, secondary -0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
4.4% [2.3%, 6.5%] 2
Regressions ❌
(secondary)
0.7% [0.4%, 0.8%] 7
Improvements ✅
(primary)
-3.5% [-5.0%, -2.6%] 3
Improvements ✅
(secondary)
-1.0% [-2.9%, -0.4%] 8
All ❌✅ (primary) -0.3% [-5.0%, 6.5%] 5

Cycles

Results (primary -0.8%, secondary -0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.1% [0.5%, 3.1%] 6
Improvements ✅
(primary)
-0.8% [-0.8%, -0.8%] 1
Improvements ✅
(secondary)
-1.3% [-4.1%, -0.5%] 10
All ❌✅ (primary) -0.8% [-0.8%, -0.8%] 1

Binary size

Results (primary -0.2%, secondary -0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.0%] 1
Regressions ❌
(secondary)
7.8% [7.8%, 7.8%] 1
Improvements ✅
(primary)
-0.2% [-0.7%, -0.0%] 51
Improvements ✅
(secondary)
-0.4% [-0.5%, -0.0%] 41
All ❌✅ (primary) -0.2% [-0.7%, 0.0%] 52

Bootstrap: 778.613s -> 778.03s (-0.07%)
Artifact size: 370.16 MiB -> 370.29 MiB (0.03%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels May 31, 2025
@scottmcm
Copy link
Member Author

icount changes are neutral (slightly green overall, but too few to really say that matters), bootstrap is slightly faster, and there's a small but pervasive binary size improvement (not just for debug either, with cargo & image improving in opt-full). Seems good to go to me.

@bors r=workingjubilee

@bors
Copy link
Collaborator

bors commented May 31, 2025

📌 Commit 4668124 has been approved by workingjubilee

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 May 31, 2025
@bors
Copy link
Collaborator

bors commented May 31, 2025

⌛ Testing commit 4668124 with merge f0999ff...

@bors
Copy link
Collaborator

bors commented Jun 1, 2025

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing f0999ff to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 1, 2025
@bors bors merged commit f0999ff into rust-lang:master Jun 1, 2025
10 checks passed
@rustbot rustbot added this to the 1.89.0 milestone Jun 1, 2025
Copy link
Contributor

github-actions bot commented Jun 1, 2025

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 4d08223 (parent) -> f0999ff (this PR)

Test differences

Show 104 test diffs

104 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 f0999ffdc4818e498949d3b1f2a0ce6be02a0436 --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. x86_64-apple-2: 3869.9s -> 5396.2s (39.4%)
  2. dist-aarch64-linux: 7977.2s -> 5419.4s (-32.1%)
  3. aarch64-apple: 4583.6s -> 5280.1s (15.2%)
  4. x86_64-apple-1: 7436.7s -> 6663.1s (-10.4%)
  5. x86_64-gnu-stable: 6844.3s -> 7519.1s (9.9%)
  6. mingw-check: 1256.5s -> 1347.6s (7.3%)
  7. dist-x86_64-netbsd: 4935.4s -> 5256.0s (6.5%)
  8. dist-aarch64-apple: 5459.8s -> 5167.6s (-5.4%)
  9. dist-x86_64-apple: 7510.2s -> 7862.0s (4.7%)
  10. dist-apple-various: 6066.1s -> 6334.0s (4.4%)
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 (f0999ff): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.3% [0.2%, 0.4%] 3
Improvements ✅
(primary)
-1.2% [-1.3%, -1.1%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -1.2% [-1.3%, -1.1%] 2

Max RSS (memory usage)

Results (primary -0.0%, secondary -0.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
4.4% [1.5%, 7.3%] 3
Regressions ❌
(secondary)
1.1% [0.6%, 2.6%] 4
Improvements ✅
(primary)
-3.3% [-4.2%, -1.3%] 4
Improvements ✅
(secondary)
-1.8% [-5.6%, -0.5%] 7
All ❌✅ (primary) -0.0% [-4.2%, 7.3%] 7

Cycles

Results (secondary -0.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.5% [0.4%, 2.6%] 5
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.4% [-6.0%, -0.4%] 12
All ❌✅ (primary) - - 0

Binary size

Results (primary -0.2%, secondary -0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.3% [0.1%, 0.5%] 2
Regressions ❌
(secondary)
3.9% [0.1%, 7.8%] 2
Improvements ✅
(primary)
-0.2% [-1.0%, -0.0%] 54
Improvements ✅
(secondary)
-0.4% [-0.5%, -0.0%] 40
All ❌✅ (primary) -0.2% [-1.0%, 0.5%] 56

Bootstrap: 776.152s -> 774.682s (-0.19%)
Artifact size: 372.23 MiB -> 372.26 MiB (0.01%)

@Mark-Simulacrum Mark-Simulacrum added the perf-regression-triaged The performance regression has been triaged. label Jun 2, 2025
@Mark-Simulacrum
Copy link
Member

Within noise threshold for (new) regressed benchmark, otherwise see #139118 (comment)

github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Jun 3, 2025
…ic, r=workingjubilee

`slice.get(i)` should use a slice projection in MIR, like `slice[i]` does

`slice[i]` is built-in magic, so ends up being quite different from `slice.get(i)` in MIR, even though they're both doing nearly identical operations -- checking the length of the slice then getting a ref/ptr to the element if it's in-bounds.

This PR adds a `slice_get_unchecked` intrinsic for `impl SliceIndex for usize` to use to fix that, so it no longer needs to do a bunch of lines of pointer math and instead just gets the obvious single statement.  (This is *not* used for the range versions, since `slice[i..]` and `slice[..k]` can't use the mir Slice projection as they're using fenceposts, not indices.)

I originally tried to do this with some kind of GVN pattern, but realized that I'm pretty sure it's not legal to optimize `BinOp::Offset` to `PlaceElem::Index` without an extremely complicated condition.  Basically, the problem is that the `Index` projection on a dereferenced slice pointer *cares about the metadata*, since it's UB to `PlaceElem::Index` outside the range described by the metadata.  But then you cast the fat pointer to a thin pointer then offset it, that *ignores* the slice length metadata, so it's possible to write things that are legal with `Offset` but would be UB if translated in the obvious way to `Index`.  Checking (or even determining) the necessary conditions for that would be complicated and error-prone, whereas this intrinsic-based approach is quite straight-forward.

Zero backend changes, because it just lowers to MIR, so it's already supported naturally by CTFE/Miri/cg_llvm/cg_clif.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants