-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
IR verification error during testing of UnicodePlots.jl #52858
Labels
bug
Indicates an unexpected problem or unintended behavior
compiler:optimizer
Optimization passes (mostly in base/compiler/ssair/)
Comments
maleadt
added
bug
Indicates an unexpected problem or unintended behavior
compiler:optimizer
Optimization passes (mostly in base/compiler/ssair/)
labels
Jan 11, 2024
At least in the reproducer this is a bug in CompactPeekIterator. I'll try to fix it. |
Keno
added a commit
that referenced
this issue
Jan 11, 2024
When IncremetnalCompact deletes and edge between blocks, it needs to go to the target and delete any reference to the edge from the PhiNodes therein. What happened in #52858, is that we had a situtation like: ``` # Block n-1 %a Expr(...) Expr(...) # <- This node is pending at the start of compaction # Block n %b PhiNode ``` To do the deletion, we use `CompactPeekIterator`, which gets a list of original statements and iterates over all the statements inside the range, including pending ones. However, there is a semantic confusion about whether to include all all statements since the previous statement (%a above), or only those statements that are actually attached to the first instruction (%b above). This of course doesn't really matter usually unless you're at a BasicBlock boundary. For the present case, we really do not want the instructions in the previous basic block - the iteration of PhiNodes terminates if it seems a stmt that cannot be in the phi block, so mistakenly seeing one of those instructions causes it to fail to fix a PhiNode that it should have, causing #52858. We fix #52858 by giving the CompactPeekIterator a flag to only return stmts in the correct basic block. While we're at it, also fix the condition for what kinds of statements are allowed in the phi block, as that was clarified more recently than this code was written.
Keno
added a commit
that referenced
this issue
Jan 12, 2024
#52863) When IncremetnalCompact deletes and edge between blocks, it needs to go to the target and delete any reference to the edge from the PhiNodes therein. What happened in #52858, is that we had a situtation like: ``` # Block n-1 %a Expr(...) Expr(...) # <- This node is pending at the start of compaction # Block n %b PhiNode ``` To do the deletion, we use `CompactPeekIterator`, which gets a list of original statements and iterates over all the statements inside the range, including pending ones. However, there is a semantic confusion about whether to include all all statements since the previous statement (%a above), or only those statements that are actually attached to the first instruction (%b above). This of course doesn't really matter usually unless you're at a BasicBlock boundary. For the present case, we really do not want the instructions in the previous basic block - the iteration of PhiNodes terminates if it seems a stmt that cannot be in the phi block, so mistakenly seeing one of those instructions causes it to fail to fix a PhiNode that it should have, causing #52858. We fix #52858 by giving the CompactPeekIterator a flag to only return stmts in the correct basic block. While we're at it, also fix the condition for what kinds of statements are allowed in the phi block, as that was clarified more recently than this code was written.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Indicates an unexpected problem or unintended behavior
compiler:optimizer
Optimization passes (mostly in base/compiler/ssair/)
As seen during testing of UnicodePlots.jl with
-g2
:Reduced to:
Bisected to #51754; cc @Keno. This is a different issue than #52846, and #52853 does not fix it.
The text was updated successfully, but these errors were encountered: