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

Which MIR passes should run on generator drop shims? #91576

Open
ecstatic-morse opened this issue Dec 6, 2021 · 3 comments
Open

Which MIR passes should run on generator drop shims? #91576

ecstatic-morse opened this issue Dec 6, 2021 · 3 comments
Assignees
Labels
A-coroutines Area: Coroutines A-mir Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Dec 6, 2021

Under normal circumstances, MIR shims have the following 5 passes applied:

However, generator drop shims are created by cloning the MIR for the original generator (?), which means they start out in MirPhase::GeneratorLowering. Prior to #91475, run_passes silently returned without doing anything if the MirPhase was greater than or equal to the expected one, so the aforementioned MIR passes were never executed. That behavior was only relevant when building drop shims, so #91475 added an explicit check to preserve it.

Was this intentional? Notably AddMovesForPackedDrops and AbortUnwindingCalls have soundness implications, and CriticalCallEdges is needed to work around some codegen issues, so it seems like they should always run. However, they might not be applicable to generators specifically.

Perhaps @tmandry knows the answer, or knows someone who does?

@tmandry
Copy link
Member

tmandry commented Dec 7, 2021

I'm not sure why those passes aren't run, and I haven't done much on the code with drop shims. @Zoxc might know. @jonas-schievink also made some recent-ish changes in that code.

@tmiasko
Copy link
Contributor

tmiasko commented Dec 7, 2021

The AddMovesForPackedDrops and AbortUnwindingCalls should at some point run on drop shim MIR. As far as I can see, precisely because the drop shim starts as a clone of original MIR those passes are already in effect. (There are new drop terminators introduced afterwards, to drop a generator in an unresumed state, but since generator itself is not packed and drops are shallow that seems fine, since those drops will be responsible for introducing any extra moves as necessary).

On the other hand, the omission of CriticalCallEdges immediately before the code generation might be problematic.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 8, 2021
…anup, r=oli-obk

Address some FIXMEs left over from rust-lang#91475

This shouldn't change behavior, only clarify what we're currently doing. I filed rust-lang#91576 to see if the treatment of generator drop shims is intentional.

cc rust-lang#91475
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 8, 2021
…anup, r=oli-obk

Address some FIXMEs left over from rust-lang#91475

This shouldn't change behavior, only clarify what we're currently doing. I filed rust-lang#91576 to see if the treatment of generator drop shims is intentional.

cc rust-lang#91475
@RalfJung
Copy link
Member

RalfJung commented Dec 21, 2022

This issue also means that MIR validation doesn't run on generator drop shims, which makes me uneasy. Or has the validator been run somewhere earlier?

the drop shim starts as a clone of original MIR

Which original MIR and where/how is that generated?

Prior to #91475, run_passes silently returned without doing anything if the MirPhase was greater than or equal to the expected one, so the aforementioned MIR passes were never executed. That behavior was only relevant when building drop shims, so #91475 added an explicit check to preserve it.

What would go wrong if this made the same run_passes call as the other shims?

@Dylan-DPC Dylan-DPC added A-mir Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html C-bug Category: This is a bug. labels Feb 16, 2023
@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
@tmiasko tmiasko self-assigned this Nov 19, 2023
@tmiasko tmiasko added the A-coroutines Area: Coroutines label Nov 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-coroutines Area: Coroutines A-mir Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants