-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Generate getelementptr
instead of inttoptr
for ptr::invalid
#121242
Conversation
rustbot has assigned @Mark-Simulacrum. Use r? to explicitly pick a reviewer |
49c5206
to
721f991
Compare
tests/codegen/strict-provenance.rs
Outdated
#[no_mangle] | ||
fn invalid(addr: usize) -> *const () { | ||
// CHECK: start | ||
// CHECK-NEXT: %0 = getelementptr i8, ptr null, i64 %addr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, nice touch. Yeah, today this is inttoptr
, so less of that sounds good to me.
EDIT: Doh, you had a better link in the OP 🤦
@bors r+ |
721f991
to
bb399b1
Compare
@bors=scottmcm,Nilstrieb |
@bors r=scottmcm,Nilstrieb |
…e, r=<try> Lower transmutes from int to pointer type as gep on null I thought of this while looking at rust-lang#121242 The UI test that's being changed here crashes without changing the transmutes into casts. Based on that, this PR should not be merged without a crater build-and-test run.
…tmcm,Nilstrieb Generate `getelementptr` instead of `inttoptr` for `ptr::invalid` Currently, `ptr::invalid` [generates an `inttoptr`](https://godbolt.org/z/3cj15dEG1), which means LLVM doesn't know that the pointer shouldn't have provenance. This PR changes the implementation so that a `getelementptr` relative to the null pointer is generated, which LLVM knows not to have provenance.
Generate `getelementptr` instead of `inttoptr` for `ptr::invalid` Currently, `ptr::invalid` [generates an `inttoptr`](https://godbolt.org/z/3cj15dEG1), which means LLVM doesn't know that the pointer shouldn't have provenance. This PR changes the implementation so that a `getelementptr` relative to the null pointer is generated, which LLVM knows not to have provenance.
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Looks like mir-opt tests need blessing? |
As @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Generate `getelementptr` instead of `inttoptr` for `ptr::invalid` Currently, `ptr::invalid` [generates an `inttoptr`](https://godbolt.org/z/3cj15dEG1), which means LLVM doesn't know that the pointer shouldn't have provenance. This PR changes the implementation so that a `getelementptr` relative to the null pointer is generated, which LLVM knows not to have provenance.
Even with EDIT: Ah, mir-opt tests. So it's about the MIR inliner, not the LLVM one. |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (f186eed): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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 @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Binary sizeResultsThis 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.
Bootstrap: 653.837s -> 655.456s (0.25%) |
With #121282 looking like it might be able to land, maybe we won't end up needing this one after all? |
…e, r=scottmcm Lower transmutes from int to pointer type as gep on null I thought of this while looking at rust-lang#121242. See that PR's description for why this lowering is preferable. The UI test that's being changed here crashes without changing the transmutes into casts. Based on that, this PR should not be merged without a crater build-and-test run.
Definitely, and when looking at the compile-time regressions this causes, that's a good thing. |
…tmcm Lower transmutes from int to pointer type as gep on null I thought of this while looking at rust-lang/rust#121242. See that PR's description for why this lowering is preferable. The UI test that's being changed here crashes without changing the transmutes into casts. Based on that, this PR should not be merged without a crater build-and-test run.
…tmcm Lower transmutes from int to pointer type as gep on null I thought of this while looking at rust-lang/rust#121242. See that PR's description for why this lowering is preferable. The UI test that's being changed here crashes without changing the transmutes into casts. Based on that, this PR should not be merged without a crater build-and-test run.
…tmcm Lower transmutes from int to pointer type as gep on null I thought of this while looking at rust-lang/rust#121242. See that PR's description for why this lowering is preferable. The UI test that's being changed here crashes without changing the transmutes into casts. Based on that, this PR should not be merged without a crater build-and-test run.
Currently,
ptr::invalid
generates aninttoptr
, which means LLVM doesn't know that the pointer shouldn't have provenance. This PR changes the implementation so that agetelementptr
relative to the null pointer is generated, which LLVM knows not to have provenance.