-
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
MIR inlining leads to LLVM error around box_free #50041
Comments
This is what
Edit: and what the llvm-ir, as disassembled from
|
The problem is that the code path bb1->bb9->bb21->bb20 in IR, corresponding to bb0->bb1->bb6->bb5 in MIR, is impossible, yet exists. And in that code path, |
And the answer to that last question is false edges, according to the following MIR from the mir_map pass:
|
Actually, the path bb0->bb7->bb4->bb10->bb12 has |
The weird switch that eventually causes the LLVM problem is added by the elaborate-drops pass. The MIR after that phase looks like the following:
|
I think the most relevant fact is this difference between MIR inlining being enabled or not:
becomes the following IR:
becomes
whiich is weird... where did the extra code go? |
The |
rustc_trans: also check dominators for SSA values in mir::analyze Fixes #50041
AFAICT the test case never landed alongside the fix for the issue.
…ark-Simulacrum Add a regression test for rust-lang#50041 AFAICT the test case never landed alongside the fix for the issue.
…ark-Simulacrum Add a regression test for rust-lang#50041 AFAICT the test case never landed alongside the fix for the issue.
Rollup of 17 pull requests Successful merges: - rust-lang#78455 (Introduce {Ref, RefMut}::try_map for optional projections in RefCell) - rust-lang#80144 (Remove giant badge in README) - rust-lang#80614 (Explain why borrows can't be held across yield point in async blocks) - rust-lang#80670 (TrustedRandomAaccess specialization composes incorrectly for nested iter::Zips) - rust-lang#80681 (Clarify what the effects of a 'logic error' are) - rust-lang#80764 (Re-stabilize Weak::as_ptr and friends for unsized T) - rust-lang#80901 (Make `x.py --color always` apply to logging too) - rust-lang#80902 (Add a regression test for rust-lang#76281) - rust-lang#80941 (Do not suggest invalid code in pattern with loop) - rust-lang#80968 (Stabilize the poll_map feature) - rust-lang#80971 (Put all feature gate tests under `feature-gates/`) - rust-lang#81021 (Remove doctree::Import) - rust-lang#81040 (doctest: Reset errors before dropping the parse session) - rust-lang#81060 (Add a regression test for rust-lang#50041) - rust-lang#81065 (codegen_cranelift: Fix redundant semicolon warn) - rust-lang#81069 (Add sample code for Rc::new_cyclic) - rust-lang#81081 (Add test for rust-lang#34792) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Context: In order to experiment with an
Alloc
-awareBox
, I was preparing to modify thebox_free
lang item signature, and my first step was to ensure MIR passes the right type to begin with, as noted inrust/src/librustc_mir/transform/inline.rs
Lines 465 to 467 in b91e6a2
Legitimately, I assumed that the MIR inline code was doing the right thing, so I mimicked it in
elaborate_drops.rs
. The resulting code actually works fine, as far as completing the 3 stages of rustc bootstrapping is involved.But before going the
box_free
route for theAlloc
-awareBox
, I first tried removing the special handling ofBox
'sDrop
, trying to leave it toboxed.rs
, shortcutting thebox_free
lang item. This didn't go well, and produced a stage 1 compiler that would crash on a badfree
in libsyntax'sThinVec
. From which I derived a small test case that would exhibit the problem with my code. Anyways, I was going well over my head with this approach, thus switched to thebox_free
signature change.So, what's the deal with this issue, will you ask? Well, it turns out that my MIR changes, essentially copied from MIR inlining, while they worked to produce an apparently working compiler, failed to compile that reduced testcase with an LLVM ERROR. I was wondering if I did something significantly different from what the MIT inlining pass was doing, so I tried to trigger it manually (since it's not enabled by default), and after some trial and error, got it to happen on a plain nightly compiler, with the following reduced testcase:
Building with
rustc +nightly -Z mir_opt_level=2 test.rs
yields:(Note the
#[inline(always)]
is only there to force MIR inlining to happen without having to go over the required threshold ; liballoc'sbox_free
has#[inline]
; similarly, the#[inline(never)]
ondealloc
avoids inlining of dealloc, to limit the effects on the MIR)Interestingly enough,
--emit mir
and--emit llvm-ir
fail with the same error. The former outputs a truncated MIR (truncated at the entry of the first basic block), and the latter outputs nothing.The text was updated successfully, but these errors were encountered: