-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Missed optimization with NonNull::new
then pointer::wrapping_byte_add(1)
then NonNull::new
then Option::unwrap
then NonNull::len
in some situtations
#120440
Labels
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
C-optimization
Category: An issue highlighting optimization opportunities or PRs implementing such
E-needs-test
Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
I-slow
Issue: Problems and improvements with respect to performance of generated code.
Comments
This comment was marked as resolved.
This comment was marked as resolved.
NonNull::new
then pointer::wrapping_byte_offset(1)
then NonNull::new
then NonNull::len
in some situtationsNonNull::new
then pointer::wrapping_byte_add(1)
then NonNull::new
then NonNull::len
in some situtations
NonNull::new
then pointer::wrapping_byte_add(1)
then NonNull::new
then NonNull::len
in some situtationsNonNull::new
then pointer::wrapping_byte_add(1)
then NonNull::new
then Option::unwrap
then NonNull::len
in some situtations
I believe this is fixed in LLVM 18. |
Confirmed fixed by #120055, needs codegen test. |
tesuji
added a commit
to tesuji/rustc
that referenced
this issue
May 20, 2024
tesuji
added a commit
to tesuji/rustc
that referenced
this issue
Jun 8, 2024
tesuji
added a commit
to tesuji/rustc
that referenced
this issue
Jun 9, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 9, 2024
Add codegen tests for E-needs-test close rust-lang#36010 close rust-lang#68667 close rust-lang#74938 close rust-lang#83585 close rust-lang#93036 close rust-lang#109328 close rust-lang#110797 close rust-lang#111508 close rust-lang#112509 close rust-lang#113757 close rust-lang#120440 close rust-lang#118392 close rust-lang#71096 r? nikic
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 10, 2024
Add codegen tests for E-needs-test close rust-lang#36010 close rust-lang#68667 close rust-lang#74938 close rust-lang#83585 close rust-lang#93036 close rust-lang#109328 close rust-lang#110797 close rust-lang#111508 close rust-lang#112509 close rust-lang#113757 close rust-lang#120440 close rust-lang#118392 close rust-lang#71096 r? nikic
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 11, 2024
Add codegen tests for E-needs-test close rust-lang#36010 close rust-lang#68667 close rust-lang#74938 close rust-lang#83585 close rust-lang#93036 close rust-lang#109328 close rust-lang#110797 close rust-lang#111508 close rust-lang#112509 close rust-lang#113757 close rust-lang#120440 close rust-lang#118392 close rust-lang#71096 r? nikic
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 13, 2024
Add codegen tests for E-needs-test close rust-lang#36010 close rust-lang#68667 close rust-lang#74938 close rust-lang#83585 close rust-lang#93036 close rust-lang#109328 close rust-lang#110797 close rust-lang#111508 close rust-lang#112509 close rust-lang#113757 close rust-lang#120440 close rust-lang#118392 close rust-lang#71096 r? nikic
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
C-optimization
Category: An issue highlighting optimization opportunities or PRs implementing such
E-needs-test
Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
I-slow
Issue: Problems and improvements with respect to performance of generated code.
(Title is a mess, but I didn't really find a simpler reproducer)
I tried this code:
(Slice element type
u8
is not important. Context: stable polyfill for<*const [T]>::len
.slice_ptr_len_3
is essentially justslice_ptr_len_1
but with the.len()
factored out into a separate function.)I expected to see this happen: With optimizations, all three fns compile to roughly the same asm, with no panic or branches.
Instead, this happened: The first has a(n unreachable) panic branch, the second and third do not.
Godbolt link
(tested on nightly
x86_64-unknown-linux-gnu
, similar on other versions/targets.//
comments mine)LLVM IR
rustc -OO --emit=llvm-ir
Meta
rustc --version --verbose
:(result is the roughly same on stable and nightly.
wrapping_byte_add
was stabilized in 1.75.0, so this doesn't compile with stable versions before that)The text was updated successfully, but these errors were encountered: