-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add test for #59352 #77693
Add test for #59352 #77693
Conversation
Not sure what happened here: This PR never got an assignee! Must have been a highfive bug. |
r? @oli-obk cc @rust-lang/wg-mir-opt How do we feel about a codegen test using mir-opt-level=2? It feels like we should maybe not land this for now (i.e. close) until it actually touches on behavior users can expect to see on stable; in particular my impression was that the various MIR opt levels are not very stable so we shouldn't really rely on them. I guess this might be better suited as a mir-opt test that can explicitly check we're performing the inlining here? |
I agree with you on most points, but the particular issue isn't about mir inlining, but a generated code performance regression. I believe mir-inlining itself wouldn't be a representative test for said issue. |
Ideally we'd have this happen entirely in MIR, but I don't see our current optimizations being up to the task. So... what do you think about a mix? This test as a regression test with the same test as a mir-opt test. Both tests should have comments referencing each other, so we can remove the LLVM test once mir-opts guarantee that the panic is compiled out even before going to LLVM. |
Sounds good to me |
Ping from triage: @bugadani could you address Oli's comment? Thanks! |
@oli-obk I'm not exactly sure this is what you had in mind, but I added a mir-opt test that will actually fail when the panic gets optimized away. I kept the mir-opt-level=2 in that test so that the test output directly shows the panic. |
Thanks, this is exactly what I had in mind. That test shows a few different things that we'll need to optimize in MIR before getting that panic optimized out. @bors r+ rollup |
📌 Commit a0c5857 has been approved by |
…laumeGomez Rollup of 6 pull requests Successful merges: - rust-lang#77693 (Add test for rust-lang#59352) - rust-lang#80515 (Improve JS performance by storing length before comparing to it in loops) - rust-lang#81030 (Update mdbook) - rust-lang#81033 (Remove useless `clean::Variant` struct) - rust-lang#81049 (inline: Round word-size cost estimates up) - rust-lang#81054 (Drop a few unneeded borrows) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Issue #59352 reported an optimization regression with rustc 1.32.0+. That regression could be tracked to a change that caused a function to miss the size limit of llvm's inlining, which results in an unreachable panicing branch being generated.
Enabling mir inline solves the issue, but is currently only done for
mir-opt-level>=2
.This PR adds a test that can serve as a regression test for #59352, if/when mir inlining gets mature enough for opt-level 1, or some other optimization can remove the panic.