Skip to content

[mir-opt] Allow SRoA when an object is transmuted to a field type#158291

Draft
scottmcm wants to merge 1 commit into
rust-lang:mainfrom
scottmcm:even-better-read-unaligned
Draft

[mir-opt] Allow SRoA when an object is transmuted to a field type#158291
scottmcm wants to merge 1 commit into
rust-lang:mainfrom
scottmcm:even-better-read-unaligned

Conversation

@scottmcm

@scottmcm scottmcm commented Jun 23, 2026

Copy link
Copy Markdown
Member

Inspired by #158202 (comment), this allows SRoA to expand a local consumed by a CastKind::Transmute if that transmute is to the type of a field, since if it's to the type of a field we can just have it take the local for that field like we would if it was a field projection.

Future PRs could do more complex stuff, like using layout to always allow SRoA of x in Transmute(x) when x is https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/layout/type.TyAndLayout.html#method.non_1zst_field, but this is enough for the specific case I needed.

r? mir-opt

@rustbot

rustbot commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@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. labels Jun 23, 2026
@scottmcm scottmcm added the A-mir-opt Area: MIR optimizations label Jun 24, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Jul 1, 2026
…d, r=aapoalas

Implement `ptr::{read,write}_unaligned` via `repr(packed)`

We already support doing unaligned reads & writes via `repr(packed)` fields, so this just uses that support from the backend rather than needing to thinks about `memcpy` and `intrinsics::forget` and such.

Turns out in codegen this ends up essentially identical because the packed type read gets `BackendRepr::Memory` and thus the read/write of the packed type *is* an `align 1` memcpy, just like the library code before this PR.  But doing this gives much simpler MIR and rust-lang#158291 will make it better than the previous version by not needing to emit the `memcpy` at all for things like `read_unaligned::<u32>`.

First commit are some tests that pass on master; Second commit changes the implementation and shows the corresponding test changes.

r? libs
jhpratt added a commit to jhpratt/rust that referenced this pull request Jul 1, 2026
…d, r=aapoalas

Implement `ptr::{read,write}_unaligned` via `repr(packed)`

We already support doing unaligned reads & writes via `repr(packed)` fields, so this just uses that support from the backend rather than needing to thinks about `memcpy` and `intrinsics::forget` and such.

Turns out in codegen this ends up essentially identical because the packed type read gets `BackendRepr::Memory` and thus the read/write of the packed type *is* an `align 1` memcpy, just like the library code before this PR.  But doing this gives much simpler MIR and rust-lang#158291 will make it better than the previous version by not needing to emit the `memcpy` at all for things like `read_unaligned::<u32>`.

First commit are some tests that pass on master; Second commit changes the implementation and shows the corresponding test changes.

r? libs
@scottmcm scottmcm force-pushed the even-better-read-unaligned branch from 7ed426a to fd33c1f Compare July 2, 2026 05:30
@rustbot

rustbot commented Jul 2, 2026

Copy link
Copy Markdown
Collaborator

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.

@scottmcm scottmcm force-pushed the even-better-read-unaligned branch from fd33c1f to a576ef9 Compare July 2, 2026 05:35
Comment on lines -42 to +41
StorageLive(_4);
_4 = copy (*_3);
_5 = copy _4 as T (Transmute);
StorageDead(_4);
_4 = copy ((*_3).0: T);

@scottmcm scottmcm Jul 2, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

The library change to use packed landed in #158427, so now this shows the critical change from this optimization...

View changes since the review

Comment on lines -25 to +26
// CHECK-NOT: !noundef
// CHECK-NOT: !range
// CHECK-SAME: !range [[R16:![0-9]+]]
// CHECK-SAME: !noundef

@scottmcm scottmcm Jul 2, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

...which then means these loads get metadata on them without codegen changes.

View changes since the review

@scottmcm

scottmcm commented Jul 3, 2026

Copy link
Copy Markdown
Member Author

The more I poked at this the less I'm confident that SRoA is the correct answer here, especially since I tried going a bit further and ended up just getting things like this

     bb0: {
         StorageLive(_3);
         _3 = PtrMetadata(copy _1);
         StorageLive(_5);
         StorageLive(_4);
         _4 = &raw const (*_1);
-        _5 = copy _4 as std::ptr::NonNull<[T]> (Transmute);
+        _5 = copy _4 as (*const [T]) is !null (Transmute);
         StorageDead(_4);
         StorageLive(_7);
         StorageLive(_6);
         _6 = copy _5 as *mut [T] (Transmute);
         _7 = copy _6 as *mut T (PtrToPtr);
         StorageDead(_6);
-        _8 = copy _7 as std::ptr::NonNull<T> (Transmute);
+        _8 = copy _7 as (*const T) is !null (Transmute);
         StorageDead(_7);
         StorageDead(_5);
         switchInt(const <T as std::mem::SizedTypeProperties>::IS_ZST) -> [0: bb1, otherwise: bb2];
     }

which is kinda the opposite of the direction in #153085 which I think would be nicer to see when reading the MIR.

@scottmcm scottmcm marked this pull request as draft July 3, 2026 11:18
@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 Jul 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-mir-opt Area: MIR optimizations S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants