Preserve metadata like !range and !nonnull in unaligned operations

[scottmcm]

Today, unaligned loads lose their !range metadata in codegen: https://rust.godbolt.org/z/rjdq51o7E

That's because it goes through copy_nonoverlapping::<u8>, it seems, which is an untyped copy so that's what the load ends up being.

I started fixing that in codegen, adding an intrinsic with fallback mir since it'd be easy to emit in cg_ssa by setting the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html#structfield.align to Align::ONE.

But then I realized that we have a way to do that in native Rust: repr(packed).

Unfortunately just doing it in pure rust in the library isn't enough because reading a repr(packed) type again emits a llvm.memcpy, leading to the same problem. (This is because all packed types end up with BackendRepr::Memoryhttps://rust.godbolt.org/z/37dee8dqr it looks like.)

But that's ok, since it's still possible to do this in MIR that all the backends already need to handle 🎉

cc @RalfJung who I'm confident will have opinions about these new intrinsics

[rustbot]

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

⚠️#[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[scottmcm]

You know what, thinking about this today, I might be able to just do this with a MIR-opt instead.

The problem I hit was basically

_3 = Packed(_2);*_1 = move _3;

and I can probably GVN that to

(*_1).0 = _2;

instead of needing the intrinsic to do it...

@rustbot author

---

EDIT: well, probably not GVN actually, but maybe SRoA?

[scottmcm]

First step of the new approach is in #158291

Pulled the test out into #158341

[scottmcm]

Today, unaligned loads lose their !range metadata in codegen: https://rust.godbolt.org/z/rjdq51o7E

That's because it goes through copy_nonoverlapping::<u8>, it seems, which is an untyped copy so that's what the load ends up being.

I started fixing that in codegen, adding an intrinsic with fallback mir since it'd be easy to emit in cg_ssa by setting the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html#structfield.align to Align::ONE.

But then I realized that we have a way to do that in native Rust: repr(packed).

Unfortunately just doing it in pure rust in the library isn't enough because reading a repr(packed) type again emits a llvm.memcpy, leading to the same problem. (This is because all packed types end up with BackendRepr::Memoryhttps://rust.godbolt.org/z/37dee8dqr it looks like.)

But that's ok, since it's still possible to do this in MIR that all the backends already need to handle 🎉

cc @RalfJung who I'm confident will have opinions about these new intrinsics

[rustbot]

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

⚠️#[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[scottmcm]

You know what, thinking about this today, I might be able to just do this with a MIR-opt instead.

The problem I hit was basically

_3 = Packed(_2);*_1 = move _3;

and I can probably GVN that to

(*_1).0 = _2;

instead of needing the intrinsic to do it...

@rustbot author

---

EDIT: well, probably not GVN actually, but maybe SRoA?

[scottmcm]

First step of the new approach is in #158291

Pulled the test out into #158341

[scottmcm]

Today, unaligned loads lose their !range metadata in codegen: https://rust.godbolt.org/z/rjdq51o7E

That's because it goes through copy_nonoverlapping::<u8>, it seems, which is an untyped copy so that's what the load ends up being.

I started fixing that in codegen, adding an intrinsic with fallback mir since it'd be easy to emit in cg_ssa by setting the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html#structfield.align to Align::ONE.

But then I realized that we have a way to do that in native Rust: repr(packed).

Unfortunately just doing it in pure rust in the library isn't enough because reading a repr(packed) type again emits a llvm.memcpy, leading to the same problem. (This is because all packed types end up with BackendRepr::Memoryhttps://rust.godbolt.org/z/37dee8dqr it looks like.)

But that's ok, since it's still possible to do this in MIR that all the backends already need to handle 🎉

cc @RalfJung who I'm confident will have opinions about these new intrinsics

[rustbot]

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

⚠️#[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[scottmcm]

You know what, thinking about this today, I might be able to just do this with a MIR-opt instead.

The problem I hit was basically

_3 = Packed(_2);*_1 = move _3;

and I can probably GVN that to

(*_1).0 = _2;

instead of needing the intrinsic to do it...

@rustbot author

---

EDIT: well, probably not GVN actually, but maybe SRoA?

[scottmcm]

First step of the new approach is in #158291

Pulled the test out into #158341

[scottmcm]

Today, unaligned loads lose their !range metadata in codegen: https://rust.godbolt.org/z/rjdq51o7E

That's because it goes through copy_nonoverlapping::<u8>, it seems, which is an untyped copy so that's what the load ends up being.

I started fixing that in codegen, adding an intrinsic with fallback mir since it'd be easy to emit in cg_ssa by setting the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html#structfield.align to Align::ONE.

But then I realized that we have a way to do that in native Rust: repr(packed).

Unfortunately just doing it in pure rust in the library isn't enough because reading a repr(packed) type again emits a llvm.memcpy, leading to the same problem. (This is because all packed types end up with BackendRepr::Memoryhttps://rust.godbolt.org/z/37dee8dqr it looks like.)

But that's ok, since it's still possible to do this in MIR that all the backends already need to handle 🎉

cc @RalfJung who I'm confident will have opinions about these new intrinsics

[rustbot]

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

⚠️#[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[scottmcm]

You know what, thinking about this today, I might be able to just do this with a MIR-opt instead.

The problem I hit was basically

_3 = Packed(_2);*_1 = move _3;

and I can probably GVN that to

(*_1).0 = _2;

instead of needing the intrinsic to do it...

@rustbot author

---

EDIT: well, probably not GVN actually, but maybe SRoA?

[scottmcm]

First step of the new approach is in #158291

Pulled the test out into #158341

[scottmcm]

Today, unaligned loads lose their !range metadata in codegen: https://rust.godbolt.org/z/rjdq51o7E

That's because it goes through copy_nonoverlapping::<u8>, it seems, which is an untyped copy so that's what the load ends up being.

I started fixing that in codegen, adding an intrinsic with fallback mir since it'd be easy to emit in cg_ssa by setting the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html#structfield.align to Align::ONE.

But then I realized that we have a way to do that in native Rust: repr(packed).

Unfortunately just doing it in pure rust in the library isn't enough because reading a repr(packed) type again emits a llvm.memcpy, leading to the same problem. (This is because all packed types end up with BackendRepr::Memoryhttps://rust.godbolt.org/z/37dee8dqr it looks like.)

But that's ok, since it's still possible to do this in MIR that all the backends already need to handle 🎉

cc @RalfJung who I'm confident will have opinions about these new intrinsics

[rustbot]

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

⚠️#[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[scottmcm]

You know what, thinking about this today, I might be able to just do this with a MIR-opt instead.

The problem I hit was basically

_3 = Packed(_2);*_1 = move _3;

and I can probably GVN that to

(*_1).0 = _2;

instead of needing the intrinsic to do it...

@rustbot author

---

EDIT: well, probably not GVN actually, but maybe SRoA?

[scottmcm]

First step of the new approach is in #158291

Pulled the test out into #158341

[scottmcm]

Today, unaligned loads lose their !range metadata in codegen: https://rust.godbolt.org/z/rjdq51o7E

That's because it goes through copy_nonoverlapping::<u8>, it seems, which is an untyped copy so that's what the load ends up being.

I started fixing that in codegen, adding an intrinsic with fallback mir since it'd be easy to emit in cg_ssa by setting the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html#structfield.align to Align::ONE.

But then I realized that we have a way to do that in native Rust: repr(packed).

Unfortunately just doing it in pure rust in the library isn't enough because reading a repr(packed) type again emits a llvm.memcpy, leading to the same problem. (This is because all packed types end up with BackendRepr::Memoryhttps://rust.godbolt.org/z/37dee8dqr it looks like.)

But that's ok, since it's still possible to do this in MIR that all the backends already need to handle 🎉

cc @RalfJung who I'm confident will have opinions about these new intrinsics

[rustbot]

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

⚠️#[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[scottmcm]

You know what, thinking about this today, I might be able to just do this with a MIR-opt instead.

The problem I hit was basically

_3 = Packed(_2);*_1 = move _3;

and I can probably GVN that to

(*_1).0 = _2;

instead of needing the intrinsic to do it...

@rustbot author

---

EDIT: well, probably not GVN actually, but maybe SRoA?

[scottmcm]

First step of the new approach is in #158291

Pulled the test out into #158341

[scottmcm]

Today, unaligned loads lose their !range metadata in codegen: https://rust.godbolt.org/z/rjdq51o7E

That's because it goes through copy_nonoverlapping::<u8>, it seems, which is an untyped copy so that's what the load ends up being.

I started fixing that in codegen, adding an intrinsic with fallback mir since it'd be easy to emit in cg_ssa by setting the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html#structfield.align to Align::ONE.

But then I realized that we have a way to do that in native Rust: repr(packed).

Unfortunately just doing it in pure rust in the library isn't enough because reading a repr(packed) type again emits a llvm.memcpy, leading to the same problem. (This is because all packed types end up with BackendRepr::Memoryhttps://rust.godbolt.org/z/37dee8dqr it looks like.)

But that's ok, since it's still possible to do this in MIR that all the backends already need to handle 🎉

cc @RalfJung who I'm confident will have opinions about these new intrinsics

[rustbot]

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

⚠️#[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[scottmcm]

You know what, thinking about this today, I might be able to just do this with a MIR-opt instead.

The problem I hit was basically

_3 = Packed(_2);*_1 = move _3;

and I can probably GVN that to

(*_1).0 = _2;

instead of needing the intrinsic to do it...

@rustbot author

---

EDIT: well, probably not GVN actually, but maybe SRoA?

[scottmcm]

First step of the new approach is in #158291

Pulled the test out into #158341

[scottmcm]

Today, unaligned loads lose their !range metadata in codegen: https://rust.godbolt.org/z/rjdq51o7E

That's because it goes through copy_nonoverlapping::<u8>, it seems, which is an untyped copy so that's what the load ends up being.

I started fixing that in codegen, adding an intrinsic with fallback mir since it'd be easy to emit in cg_ssa by setting the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/mir/place/struct.PlaceValue.html#structfield.align to Align::ONE.

But then I realized that we have a way to do that in native Rust: repr(packed).

Unfortunately just doing it in pure rust in the library isn't enough because reading a repr(packed) type again emits a llvm.memcpy, leading to the same problem. (This is because all packed types end up with BackendRepr::Memoryhttps://rust.godbolt.org/z/37dee8dqr it looks like.)

But that's ok, since it's still possible to do this in MIR that all the backends already need to handle 🎉

cc @RalfJung who I'm confident will have opinions about these new intrinsics

[rustbot]

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

⚠️#[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

[rustbot]

r? @dingxiangfei2009

rustbot has assigned @dingxiangfei2009.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 19 candidates

[scottmcm]

You know what, thinking about this today, I might be able to just do this with a MIR-opt instead.

The problem I hit was basically

_3 = Packed(_2);*_1 = move _3;

and I can probably GVN that to

(*_1).0 = _2;

instead of needing the intrinsic to do it...

@rustbot author

---

EDIT: well, probably not GVN actually, but maybe SRoA?

[scottmcm]

First step of the new approach is in #158291

Pulled the test out into #158341