JIT: fix value numbering to handle GT_NULLCHECK more generally#18942
Conversation
With the advent of dotnet#18819 we may now see GT_NULLCHECK nodes with operands that also can cause exceptions. Handle this in value numbering. Closes #18937.
|
@briansull PTAL No diffs in the _il_relldobj_V.exe from before #18819. |
|
@echesakov can you launch one or more of the Pri1 test legs that you saw failing? |
|
@dotnet-bot test CentOS7.1 x64 Build and Test |
|
OSX failure looks like an infrastructure issue: will retry if everything else passes. |
|
No PMI diffs on x64 across all pri1 tests. No crossgen diffs for frameworks. @dotnet-bot retest OSX10.12 x64 Checked Innerloop Build and Test |
| vnStore->VNPairForFunc(TYP_REF, VNF_NullPtrExc, | ||
| vnStore->VNPNormVal(tree->gtOp.gtOp1->gtVNPair))); | ||
|
|
||
| excSet = vnStore->VNPExcSetUnion(excSet, vnStore->VNPExcVal(tree->gtOp.gtOp1->gtVNPair)); |
There was a problem hiding this comment.
I think that we should declare a new local excSetBoth or similar instead of stomping on the old value of excSet
| vnStore->VNPairForFunc(TYP_REF, VNF_NullPtrExc, | ||
| tree->gtOp.gtOp1->gtVNPair))); | ||
| break; | ||
| // Handle case where operand tree also may case exceptions. |
|
OSX testing now failing with some pal test errors. Am going to push an update with changes from feedback and ignore OSX if it fails again. |
4 participants
With the advent of #18819 we may now see GT_NULLCHECK nodes with operands
that also can cause exceptions.
Handle this in value numbering.
Closes #18937.