Fix System.Numerics.Vectors CoreFx test failures#9496
Fix System.Numerics.Vectors CoreFx test failures#9496CarolEidt merged 1 commit intodotnet:masterfrom
Conversation
CoreFx Issue 15713 is due to a case of an Indir(Addr(Field(Vector3 local))) which for some reason has a MorphAddrContext of MACK_Ind. Although I haven't fully identified why that is the case, we should be conservative in this case and mark the address as do-not-enregister. In addition, when attempting to debug this with a Checked JIT, I encountered an AV due to `GetJitTls` returning null in the `JITDUMP` calls in `getMaxIntrinsicSIMDVectorLength`. Again, I'm not sure why this would be the case but I have added guarding conditions.
|
@sivarv @BruceForstall PTAL |
|
|
| return newTree; | ||
| } | ||
| } | ||
| else if ((objRef != nullptr) && (objRef->OperGet() == GT_ADDR) && varTypeIsSIMD(objRef->gtGetOp1())) |
There was a problem hiding this comment.
I hit cases before where we were getting into MACK_Ind contexts for Vector3 field access unexpectedly, and I fixed those reasons, so I'm worried this is treating the symptom, not the cause. However, if you believe this is a good, conservative fix, then I'm ok with it.
There was a problem hiding this comment.
I'm still working on trying to figure out why we wind up in the MACK_Ind context. However, given that we do, I believe this is a conservative fix.
|
I can't reproduce the Windows_NT x64 Release failure, and it's difficult to imagine how these changes could have broken that test. Will retry. |
|
@dotnet-bot test Windows_NT x64 Release Priority 1 Build and Test |
Add a test case for PR #9496
Fix System.Numerics.Vectors CoreFx test failures Commit migrated from dotnet/coreclr@0604f7e
Commit migrated from dotnet/coreclr@106379c
Add a test case for PR dotnet/coreclr#9496 Commit migrated from dotnet/coreclr@54062ca
4 participants
CoreFx Issue 15713 is due to a case of an Indir(Addr(Field(Vector3 local))) which for some reason has a MorphAddrContext of MACK_Ind. Although I haven't fully identified why that is the case, we should be conservative in this case and mark the address as do-not-enregister.
In addition, when attempting to debug this with a Checked JIT, I encountered an AV due to
GetJitTlsreturning null in theJITDUMPcalls ingetMaxIntrinsicSIMDVectorLength. Again, I'm not sure why this would be the case but I have added guarding conditions.