Fix issues with EH in unexecuted loops #82329
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsFix two problems with code in loops that are determined to not execute that have exception handling clauses:
Fixes #81675
|
4 tasks
Fix two problems with code in loops that are determined to not execute that have exception handling clauses: 1. Be more specific in loop unrolling to avoid unrolling even zero-count loops (which causes the loop to be removed) if there is a block in the loop with a different handler region than the handler region of the "top" block. This should only kick in for x86, where handlers are not extracted as funclets. 2. In Value Numbering, before actually value numbering nodes, `optComputeLoopSideEffectsOfBlock()` walks all the blocks of all top-level loops collecting data. Unfortunately, it sets the Value Number of certain nodes as a way to pass information "up the tree" during processing. Presumably these "fake" value numbers actually get replaced during actual value numbering for the tree. However, when we go to actually value number the IR, we only walk reachable blocks. Thus, in some cases, we would end up with a top-level "fake" value number on an unreachable statement root, thus leading `fgDebugCheckExceptionSets()` to check the tree and assert. To fix this, at the end of the `optComputeLoopSideEffectsOfBlock()`, clear the VN in case it was previously set. Fixes dotnet#81675
BruceForstall
force-pushed
the
Fix81675
branch
from
da983e3 to
8102f00
Compare
|
@AndyAyersMS @jakobbotsch PTAL |
AndyAyersMS
approved these changes
Feb 22, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix two problems with code in loops that are determined to not execute that have exception handling clauses:
optComputeLoopSideEffectsOfBlock()walks all the blocks of all top-level loops collecting data. Unfortunately, it sets the Value Number of certain nodes as a way to pass information "up the tree" during processing. Presumably these "fake" value numbers actually get replaced during actual value numbering for the tree. However, when we go to actually value number the IR, we only walk reachable blocks. Thus, in some cases, we would end up with a top-level "fake" value number on an unreachable statement root, thus leadingfgDebugCheckExceptionSets()to check the tree and assert. To fix this, at the end of theoptComputeLoopSideEffectsOfBlock(), clear the VN in case it was previously set.Fixes #81675