Skip to content
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 contains StorageDead for locals that have never ben live #99085

Closed
RalfJung opened this issue Jul 9, 2022 · 3 comments
Closed

MIR contains StorageDead for locals that have never ben live #99085

RalfJung opened this issue Jul 9, 2022 · 3 comments

Comments

@RalfJung
Copy link
Member

RalfJung commented Jul 9, 2022

If I change this function to trigger an error when using StorageDead on a local that is already dead, that shows that we do generate MIR with redundant StorageDead. I am not sure if we should consider this a bug, but given that we consider redundant StorageLive a bug (due to some rather vague language on the LLVM side, that seems safer), I wonder if we should do the same for StorageDead?

Here's an execution trace (from CTFE) of such a piece of MIR:

├─┐rustc_const_eval::interpret::eval_context::frame core::num::<impl i8>::checked_div
│ ├─0ms  INFO rustc_const_eval::interpret::step // executing bb0
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageLive(_3)
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageLive(_4)
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageLive(_5)
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageLive(_6)
│ ├─0ms  INFO rustc_const_eval::interpret::step _6 = _2
│ ├─0ms  INFO rustc_const_eval::interpret::step _5 = Eq(move _6, const 0_i8)
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageDead(_6)
│ ├─0ms  INFO rustc_const_eval::interpret::step switchInt(move _5) -> [false: bb2, otherwise: bb1]
│ ├─0ms  INFO rustc_const_eval::interpret::step // executing bb2
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageLive(_7)
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageLive(_8)
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageLive(_9)
│ ├─0ms  INFO rustc_const_eval::interpret::step _9 = _1
│ ├─0ms  INFO rustc_const_eval::interpret::step _8 = Eq(move _9, const core::num::<impl i8>::MIN)
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageDead(_9)
│ ├─0ms  INFO rustc_const_eval::interpret::step switchInt(move _8) -> [false: bb4, otherwise: bb5]
│ ├─0ms  INFO rustc_const_eval::interpret::step // executing bb4
│ ├─0ms  INFO rustc_const_eval::interpret::step _7 = const false
│ ├─0ms  INFO rustc_const_eval::interpret::step goto -> bb6
│ ├─0ms  INFO rustc_const_eval::interpret::step // executing bb6
│ ├─0ms  INFO rustc_const_eval::interpret::step StorageDead(_10)

As you can see, _10 was never marked as live, and yet it is marked as dead here.

Unfortunately I do not know a good way to get the CTFE MIR of a standard library function. I tried copying its code to generate the MIR separately, but that looks pretty different from the above trace.

Cc @tmandry @JakobDegen

@RalfJung
Copy link
Member Author

RalfJung commented Jul 9, 2022

#98896 contains an example of such MIR.

@RalfJung RalfJung closed this as not planned Won't fix, can't repro, duplicate, stale Jul 9, 2022
@tmandry
Copy link
Member

tmandry commented Jul 13, 2022

@RalfJung did you mean to close this?

@RalfJung
Copy link
Member Author

Yeah, it's a duplicate of #98896.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants