Skip to content

Enable -disable-i2p-p2i-opt flag #147272

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.

Sign up for GitHub

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
+10 −2
Draft

Enable -disable-i2p-p2i-opt flag #147272

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions compiler/rustc_codegen_llvm/src/llvm_util.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -118,6 +118,8 @@ unsafe fn configure_llvm(sess: &Session) {
// Use non-zero `import-instr-limit` multiplier for cold callsites.
add("-import-cold-multiplier=0.1", false);

add("-disable-i2p-p2i-opt", false);

if sess.print_llvm_stats() {
add("-stats", false);
}
Expand Down
3 changes: 2 additions & 1 deletion tests/codegen-llvm/iter-repeat-n-trivial-drop.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,8 +47,9 @@ pub fn iter_repeat_n_next(it: &mut std::iter::RepeatN<NotCopy>) -> Option<NotCop
#[no_mangle]
// CHECK-LABEL: @vec_extend_via_iter_repeat_n
pub fn vec_extend_via_iter_repeat_n() -> Vec<u8> {
// FIXME: Has extra inttoptr + ptrtoint pair
// CHECK: %[[ADDR:.+]] = tail call {{(noalias )?}}noundef dereferenceable_or_null(1234) ptr @{{.*}}__rust_alloc(i64 noundef {{(range\(i64 1, 0\) )?}}1234, i64 noundef {{(range\(i64 1, -9223372036854775807\) )?}}1)
// CHECK: tail call void @llvm.memset.p0.i64(ptr noundef nonnull align 1 dereferenceable(1234) %[[ADDR]], i8 42, i64 1234,
// CHECK: tail call void @llvm.memset.p0.i64(ptr noundef nonnull align 1 dereferenceable(1234) %[[ADDR2:.+]], i8 42, i64 1234,

let n = 1234_usize;
let mut v = Vec::with_capacity(n);
Expand Down
4 changes: 4 additions & 0 deletions tests/codegen-llvm/try_question_mark_nop.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -212,6 +212,8 @@ pub fn control_flow_nop_traits_128(x: ControlFlow<i128, u128>) -> ControlFlow<i1
#[no_mangle]
pub fn result_nop_match_ptr(x: Result<usize, Box<()>>) -> Result<usize, Box<()>> {
// CHECK: start:
// CHECK-NEXT: ptrtoint
// CHECK-NEXT: inttoptr
// CHECK-NEXT: insertvalue { i{{[0-9]+}}, ptr }
// CHECK-NEXT: insertvalue { i{{[0-9]+}}, ptr }
// CHECK-NEXT: ret
Expand All @@ -225,6 +227,8 @@ pub fn result_nop_match_ptr(x: Result<usize, Box<()>>) -> Result<usize, Box<()>>
#[no_mangle]
pub fn result_nop_traits_ptr(x: Result<u64, NonNull<()>>) -> Result<u64, NonNull<()>> {
// CHECK: start:
// CHECK-NEXT: ptrtoint
// CHECK-NEXT: inttoptr
// CHECK-NEXT: insertvalue { i{{[0-9]+}}, ptr }
// CHECK-NEXT: insertvalue { i{{[0-9]+}}, ptr }
// CHECK-NEXT: ret
Expand Down
3 changes: 2 additions & 1 deletion tests/codegen-llvm/vec-iter-collect-len.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,10 +3,11 @@

#[no_mangle]
pub fn get_len() -> usize {
// FIXME: Allocation no longer optimized away.
// CHECK-LABEL: @get_len
// CHECK-NEXT: start:
// CHECK-NEXT: ; call __rustc::__rust_no_alloc_shim_is_unstable_v2
// CHECK-NEXT: tail call void @_R{{.+}}__rust_no_alloc_shim_is_unstable_v2()
// CHECK-NEXT: ret i{{[0-9]+}} 3
// CHECK: ret i{{[0-9]+}} 3
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think the cause of the ptrtoint/inttoptr casts in this case is SROA on something like this: https://llvm.godbolt.org/z/576Gb1fEx

Ideally this would not produce any casts (there are uses with different types, but those uses are disjoint), but if it does it's probably better to chose ptr as the common type, as ptrtoint(inttoptr) can be elided, unlike the reverse.

Copy link
Member

Choose a reason for hiding this comment

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

as ptrtoint(inttoptr) can be elided, unlike the reverse.

Are you sure that can be elided? It has the side effect of exposing the original address. I feel like you'd need to also prove that nobody knows about that address, which seems impossible?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ptrtoint will expose the provenance of the pointer returned by inttoptr. However, inttoptr can only return a previously exposed provenance. As such, ptrtoint is exposing a previously exposed provenance, and the second expose can be elided.

[1, 2, 3].iter().collect::<Vec<_>>().len()
}
Loading