-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Don't ICE in might_permit_raw_init
if reference is polymorphic
#108012
Conversation
r? @oli-obk (rustbot has picked a reviewer for you, use r? to override) |
6c854dc
to
132ee4d
Compare
This comment has been minimized.
This comment has been minimized.
13c9802
to
c7b3261
Compare
This comment has been minimized.
This comment has been minimized.
let Ok(pointee) = cx.layout_of(pointee.ty) else { | ||
// Reference is too polymorphic, it has a layout but the pointee does not. | ||
assert!(pointee.ty.needs_subst()); | ||
return false; |
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, lol, this is totally wrong. this is might_permit_raw_init_lax
, not known_to_permit_raw_init_lax
(or something worded like that) :/ this probably should return true
in that case...
@saethlin, are you sure that it's valid to instcombine away an uninit validity assertion in this case? really we should be returning something ternary -- yes, no, or "too generic" (or at least, "unknown layout"), and in the case of the last option, we don't do anything in the optimization.
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.
Not sure what you're asking, but I'll guess.
If you are asking me what the correct thing to do instead of ICEing here is, no idea. The upstream effect here should be not applying the optimization- we don't know if T
has alignment > 1, in which case the 0x1-filling is invalid.
If you're asking about the code I added to InstCombine, I intended to nab that directly from what codegen does when it decides to emit a panic or not for that intrinsic. Now it's a fair question as to whether what codegen does just behaves nonsensically when given a generic, if code is supposed to be monomorphized at that stage.
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.
What I'm saying is that it's probably not correct to return either false
(like I did) or true
(like I wanted to change when I first pointed out this comment) if we can't get the layout of the pointee here.
CI failure(edited link) shows that false
is bad because we're optimizing away perfectly fine polymorphic functions in the stdlib, and true
is also probably not great, since we're dropping this assertion which may be false later once things are monomorphized. Added a mir-opt test to show the latter behavior in the first commit in this PR.
^^^ edit: I'm not actually sure that CI failure is due to this? It's confusing why that's happening, though. We should always be going from ICE -> dropping assertions
Second PR in this stack makes the queries you added fallible, so we can handle the LayoutError
s gracefully and not perform the optimization in that case. It duplicates a bit of work, since we may have to call the layout query twice on some code paths, but oh well.
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.
and
true
is also probably not great, since we're dropping this assertion
If this function is not allowed to have false positives maybe it shouldn't be called might_
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.
The function is intended to definitely answer whether we will emit a panic or not. Optimizations shouldn't change that behavior.
We don't always emit panics fully aggressively (that depends on compiler flags), so in a sense there are false negatives allowed.
c7b3261
to
da74b09
Compare
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
da74b09
to
b096f0e
Compare
Just been musing about this... I'm pretty sure that all of the MIR optimization value derived here is from deleting the inhabited assertion. Initially I was concerned that the ICE here pointed at a deeper issue in the compiler. But if the solution that preserves the optimizations of the zero init and mem_uninit init paths costs complexity elsewhere in the compiler, or especially if it makes compilation slower due to the additional queries, we should probably just delete the InstCombine for those intrinsics, and only keep the one that checks for inhabited types. |
I don't think that this implementation is significantly more complex, and I guess we can see if compilation is slower with @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit b096f0e with merge ff2eaadf96941a226289d1d89cb63f9e7d7ef475... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (ff2eaadf96941a226289d1d89cb63f9e7d7ef475): comparison URL. Overall result: no relevant changes - no 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. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. 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.
CyclesThis benchmark run did not return any relevant results for this metric. |
@bors r+ |
⌛ Testing commit b096f0e with merge f6cc158db71213b9eb346875598970a4205d964c... |
💔 Test failed - checks-actions |
Spurious it seems @bors retry |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Finished benchmarking commit (c528357): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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.
CyclesThis benchmark run did not return any relevant results for this metric. |
Don't ICE in `might_permit_raw_init` if reference is polymorphic Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition. cc `@saethlin` fixes rust-lang#107999
Upstream PRs that require local changes: - Don't ICE in might_permit_raw_init if reference is polymorphic rust-lang/rust#108012 - Use target instead of machine for mir interpreter integer handling rust-lang/rust#108047 - Optimize mk_region rust-lang/rust#108020 Co-authored-by: Qinheping Hu <qinhh@amazon.com>
Upstream PRs that require local changes: - Don't ICE in might_permit_raw_init if reference is polymorphic rust-lang/rust#108012 - Use target instead of machine for mir interpreter integer handling rust-lang/rust#108047 - Optimize mk_region rust-lang/rust#108020 Co-authored-by: Qinheping Hu <qinhh@amazon.com>
Upstream PRs that require local changes: - Don't ICE in might_permit_raw_init if reference is polymorphic rust-lang/rust#108012 - Use target instead of machine for mir interpreter integer handling rust-lang/rust#108047 - Optimize mk_region rust-lang/rust#108020 Co-authored-by: Qinheping Hu <qinhh@amazon.com>
Emitting optimized MIR for a polymorphic function may require computing layout of a type that isn't (yet) known. This happens in the instcombine pass, for example. Let's fail gracefully in that condition.
cc @saethlin
fixes #107999