-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Change int-to-ptr transmute lowering back to inttoptr #147541
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
base: master
Are you sure you want to change the base?
Conversation
This is a mitigation for a miscompilation, and we do not have a good understanding of how widespread the miscompile is. The answer could be "very". I've started a crater run to evaluate this: #138759 (comment) but it will take a significant amount of time for results to come in. I am not sure it makes sense to wait for that crater run before making a backport decision, considering how long it will take. |
(Int(..) | Float(_), Int(..) | Float(_)) => bx.bitcast(imm, to_backend_ty), | ||
(Pointer(..), Pointer(..)) => bx.pointercast(imm, to_backend_ty), | ||
(Int(..), Pointer(..)) => bx.ptradd(bx.const_null(bx.type_ptr()), imm), | ||
(Int(..), Pointer(..)) => bx.inttoptr(imm, to_backend_ty), |
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.
Hmm, maybe we could add a BuilderMethods::inttoptr_noprovenance
for this, as that would give us a place to have a -Z
flag that affects what it does so we could put it back to the better version more easily later?
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.
(Maybe skip the -Z flag in this PR, if we want something that could go to beta, but if it existed we could test both ways in the codegen test.)
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.
Writing the actual implementation here took me about a minute, and I expect it will be similarly near-zero effort to swap it back again. Adding a helper would be more effort.
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.
It just feels like a -Z mutable-noalias
situation, where being able to test whether something is still broken without a new build is the reason to do it, not because the actual code change is hard.
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.
A dedicated method would also allow backends which don't miscompile it to keep avoiding the provenance.
Some changes occurred in compiler/rustc_codegen_ssa |
r? scottmcm |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Change int-to-ptr transmute lowering back to inttoptr
This comment has been minimized.
This comment has been minimized.
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.
Well, r=me
on the code changes if we decide this is the direction we want to go. TBH personally I'd still rather disable the problematic LLVM optimization instead, if we can.
#[no_mangle] | ||
pub fn mk_result(a: usize) -> Result<u8, *const u8> { | ||
// CHECK-LABEL: @mk_result | ||
// CHECK-NOT: unreachable |
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.
suggestion: it's always good to have positive checks too, just in case the negative thing changes, so maybe
// CHECK-NOT: unreachable | |
// CHECK-NOT: unreachable | |
// CHECK: load i8, | |
// CHECK-NOT: unreachable |
Finished benchmarking commit (9e02838): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.3%, secondary 0.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -2.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.2%, secondary -0.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 472.692s -> 472.611s (-0.02%) |
This is a revert of #121282, but with a regression test to cover the reported miscompile in #147265 that was caused by the way the code here combines with #138759.