[release/6.0] Fix VN incorrect optimizations with a new JitEEInterface function. #58005
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
with a naive implementation so far.
… type case in the managed compiler
It appeared that we have many trees where we generate unique VN for rhs and don't inform `fgValueNumberBlockAssignment` about it. For example, for ``` N005 ( 10, 8) [000033] -A--G---R--- * ASG struct (copy) N004 ( 3, 2) [000031] D------N---- +--* LCL_VAR struct<eightByteStruct, 8> V01 loc1 d:2 N003 ( 6, 5) [000030] n---G------- \--* IND struct N002 ( 3, 3) [000043] ------------ \--* ADDR byref N001 ( 3, 2) [000044] -------N---- \--* LCL_VAR struct<largeStruct, 32> V00 loc0 u:6 (last use) ``` we will generate unique rhs but then `fgValueNumberBlockAssignment` will still try to work it as with a non-unique one.
For a tree like: ``` N005 ( 11, 10) [001400] -A------R---- * ASG long N004 ( 6, 5) [001401] *------N----- +--* IND long N003 ( 3, 3) [001402] ------------- | \--* ADDR byref Zero Fseq[_00] N002 ( 3, 2) [001403] U------N----- | \--* LCL_VAR struct<System.Runtime.Intrinsics.Vector128`1[Byte], 16> V45 tmp38 ud:3->4 N001 ( 1, 1) [001404] ------------- \--* LCL_VAR long V69 tmp62 u:2 (last use) ``` SSA was working correctly and printing that `001403` is using SSA-3 and defining SSA-4. However, this code, for some reason, was writing result as a define for SSA-3.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsBackport of #57282 to release/6.0-rc1 /cc @sandreenko Customer ImpactTestingRisk
|
jakobbotsch
approved these changes
Aug 24, 2021
briansull
reviewed
Aug 24, 2021
|
|
||
| haveCorrectFieldForVN = | ||
| compiler->info.compCompHnd->doesFieldBelongToClass(field->gtFldHnd, clsHnd); | ||
| noway_assert(haveCorrectFieldForVN); |
There was a problem hiding this comment.
The new method doesFieldBelongToClass has to return true here otherwise we will terminate the program.
The only place that doesFieldBelongToClass can return false is above at line 276.
There was a problem hiding this comment.
we won't terminate the program, we will terminate the current method compilation and recompile in minopts.
jeffschwMSFT
removed
the
Servicing-consider
|
I have changed the target branch from 6.0-RC1 to 6.0 (RC2). |
jeffschwMSFT
approved these changes
Aug 26, 2021
jeffschwMSFT
changed the title
AndyAyersMS
approved these changes
Aug 27, 2021
|
@Anipik can you help merge this? The CI is green, but the build analysis shows red. |
ghost
locked as resolved and limited conversation to collaborators
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.
Backport of #57282 to release/6.0
/cc @sandreenko
Customer Impact
If the issue is not fixed it could lead to bad codegen on a simple C# code.
There are cases where crossgen2 images could have worse code because crossgen can use both canon- and exact fieldHndl and we accept only canon. The regressions are very small, in libs there is only 1 library out of 272 where it happens:
Testing
There are many tests that were failing without this fix (#42517, #49954, #54102, #56980) + many more fizzling cases.
The main PR has passed jitstress/outerloop/libraries-jitstress + all the failing tests.
Regression
Yes - #48377
Risk
Low - we have many tests cases, we understand the issue and the fix is conservative. The fix uses VM that we understand well and min changes in the Value Numbering. We have manually analyzed dozens of CI test failures, all look like CI infra noise.