Uh oh!
There was an error while loading. Please reload this page.
Remove MIR assignments to ZST types - #80493
Conversation
Uh oh!
There was an error while loading. Please reload this page.
rust-log-analyzer
commented
Dec 29, 2020
The job Click to see the possible cause of the failure (guessed by this bot) |
simonvandel
commented
Dec 29, 2020
@oli-obk I would need some help in what to do with those test errors. |
rust-log-analyzer
commented
Dec 29, 2020
The job Click to see the possible cause of the failure (guessed by this bot) |
oli-obk
commented
Dec 30, 2020
Jup, exactly what I had in mind. I just thought we already had some code for this and just forgot turning it on again, but apparently not? You can bless most tests that changed. We do need to fix |
Uh oh!
There was an error while loading. Please reload this page.
rust-log-analyzer
commented
Dec 30, 2020
The job Click to see the possible cause of the failure (guessed by this bot) |
oli-obk
commented
Dec 30, 2020
You can fix codegen tests by looking at |
simonvandel
commented
Dec 30, 2020
When the MIR does not have |
oli-obk
commented
Dec 30, 2020
@bors r+ weird... but I guess that is an independent codegen problem |
bors
commented
Dec 30, 2020
📌 Commit 22f94499cc9c397420c4cf8ba0bbcabf4018bae7 has been approved by |
wesleywiser
commented
Dec 30, 2020
@bors r- I thought we had already did this via a combination of the |
wesleywiser
commented
Dec 30, 2020
Ah, ok. I see there was discussion in #80475 about this. I'm willing to accept the logic that we never need writes of ZST values even in the return place but in that case, I think the better thing to do would be to change the logic in |
simonvandel
commented
Dec 30, 2020
I'll see how I can modify SimplifyLocals 👍 |
22f9449 to
d1a87e0Comparesimonvandel
commented
Dec 30, 2020
Force pushed a new approach that is an extension of SimplifyLocals instead. |
There was a problem hiding this comment.
We refactored this loop a few months ago to push most of this kind of logic into UsedLocals. i think that's probably the place we need to make this change.
It might just be a matter of adjusting this logic:
rust/compiler/rustc_mir/src/transform/simplify.rs
Lines 392 to 398 in e226704
There was a problem hiding this comment.
Took a stab at moving the logic into UsedLocals with the lastest commits
There was a problem hiding this comment.
I feel like this is probably invalid – for #[naked] functions to be well-formed, they usually should only contain an optional inline assembly call and ret. alloca here will likely make any use of #[naked] plain unsound.
If #[naked] wasn't as unstable as they are, this would be blocking, and IMHO it needing change now warrants at least a folllow-up issue.
There was a problem hiding this comment.
FWIW I'm pretty sure we skip codegenning ZST assignments/allocas/etc in the llvm backend which is why with _0 = const () in MIR it never generated any LLVM. Now that there are no assignments to the _0, its probably taking a different path in the backend and ends up generating the alloca anyway.
If I had to guess this local is failing to be marked as a SSA value?
There was a problem hiding this comment.
So this pr should be blocked until the codegen is fixed to not generate ZST allocas for _0 if it is not assigned in MIR?
I haven't looked at codegen before, so any pointers are appreciated.
There was a problem hiding this comment.
Yeah, that looks like a use of an uninitialized ZST local marking it as non-SSA (implicit use in return terminator?). That part would be in non_ssa_locals.
There was a problem hiding this comment.
The latest commit tries to eliminate the alloca
bors
commented
Jan 14, 2021
☔ The latest upstream changes (presumably #79328) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
I wonder if anything breaks if we do in fact just go ahead and unconditionally mark any variable without assignments as "ssa".
There was a problem hiding this comment.
I tried replacing is_zst with true which at least didn't break test/{mir-opt,codegen}. Should i push that instead of the current zst handling?
There was a problem hiding this comment.
Lets not do that in the current PR, especially because apparently this was added as part of a ICE fix, but without tests. I will experiment with it separately.
There was a problem hiding this comment.
Some assignments are not removed compared to earlier versions of this PR. Why are those not optimized now?
f1ae27c to
60b0bb3Comparerust-log-analyzer
commented
Feb 2, 2021
The job Click to see the possible cause of the failure (guessed by this bot) |
60b0bb3 to
bab2e56Compareoli-obk
commented
Feb 15, 2021
@bors r+ rollup- |
bors
commented
Feb 15, 2021
📌 Commit bab2e56 has been approved by |
bjorn3
commented
Feb 15, 2021
I think you wanted to do @bors rollup=never
|
oli-obk
commented
Feb 15, 2021
ooops, thanks. I had a feeling something was wrong when I typed that, but couldn't figure out what |
bors
commented
Feb 15, 2021
⌛ Testing commit bab2e56 with merge ef6fe77536ea1d8c722aad9fc949e031f01123c9... |
rust-log-analyzer
commented
Feb 15, 2021
The job Click to see the possible cause of the failure (guessed by this bot) |
bors
commented
Feb 15, 2021
💔 Test failed - checks-actions |
bors
commented
Feb 21, 2021
☔ The latest upstream changes (presumably #79100) made this pull request unmergeable. Please resolve the merge conflicts. |
JohnCSimon
commented
Mar 7, 2021
ping from triage: |
Based on my understanding of #80475 (comment)
r? @oli-obk