Uh oh!
There was an error while loading. Please reload this page.
Do not explicitly pass type to VNForMapStore - #61882
Conversation
The code was trying to obtain the value of the location to store to from the updated map for the element. This is simply incorrect for all but the trivial case of an empty field sequence.
It must always be equal to the type of the map being updated, not having redundancy eliminates the possibility for mistakes.
ghost
commented
Nov 20, 2021
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsNext prerequisite in preparation for typing maps with placeholder. Separate as there are significant diffs. First, there is a fix for how type mismatch was accounted for in Which is that we will no longer pass explicit types to There are significant diffs from this, because this way we fix type mismatches arising in code such as the following: privatestaticintProblem(StructWithIndexa,StructWithIndexb){a.Index=1;b=a;returnb.Index;}structStructWithIndex{publicintIndex;publicintValue;}(Struct promotion must be disabled for this sample code) Previously, when we numbered *****BB01, STMT00000(before)
N003 ( 5, 6) [000004] -A--G---R---*ASG int N002 ( 3, 4) [000003] U------N----+--*LCL_FLD int V00 arg0 ud:1->2[+0] Fseq[Index]
N001 ( 1, 1) [000002] ------------\--*CNS_INT int 1N001 [000002] CNS_INT1=> $41 {IntCns1}
VNApplySelectors:VNForHandle(Index) is $100, fieldType is int
VNForMapSelect($80, $100):int returns $140 {$80[$100]}
VNApplySelectors:VNForHandle(Index) is $100, fieldType is int
VNForMapSelect($80, $100):int returns $140 {$80[$100]}
N002 [000003] LCL_FLDV00 arg0 ud:1->2[+0] Fseq[Index] => $140 {$80[$100]}
VNApplySelectorsAssign:VNForHandle(Index) is $100, fieldType is int
VNForMapStore($80, $100, $41):int in BB01 returns $180 {$80[$100:= $41]}
VNApplySelectorsAssign:VNForHandle(Index) is $100, fieldType is int
VNForMapStore($80, $100, $41):int in BB01 returns $180 {$80[$100:= $41]}
N002 [000003] LCL_FLDV00 arg0 ud:1->2[+0] Fseq[Index] => $180 {$80[$100:= $41]}
N003 [000004] ASG=> $41 {IntCns1}This is because This lead to mismatch on copy: *****BB01, STMT00001(before)
N003 ( 7, 5) [000008] -A------R---*ASG struct (copy)
N002 ( 3, 2) [000006] D------N----+--*LCL_VAR struct<StructWithIndex, 8> V01 arg1 d:2N001 ( 3, 2) [000005] ------------\--*LCL_VAR struct<StructWithIndex, 8> V00 arg0 u:2 (last use)
N001 [000005] LCL_VARV00 arg0 u:2 (last use) => $180 {$80[$100:= $41]}
***Mismatched types in VNApplySelectorsTypeCheck (indType is TYP_STRUCT)
***Mismatched types in VNApplySelectorsTypeCheck (indType is TYP_STRUCT)
***Mismatched types in VNApplySelectorsAssignTypeCoerce (indType is TYP_STRUCT)
***Mismatched types in VNApplySelectorsAssignTypeCoerce (indType is TYP_STRUCT)
Tree [000008] assigned VN to local varV01/2: <l:$1c3 {MemOpaque:NotInLoop}, c:$1c2 {MemOpaque:NotInLoop}>
N003 [000008] ASG=> $VN.VoidAnd we lost track of the value. After this change, we no longer do, and this enables some nice improvements. Win-x64 diffsbenchmarks.run.windows.x64.checked.mch:Detail diffscoreclr_tests.pmi.windows.x64.checked.mch:Detail diffslibraries.pmi.windows.x64.checked.mch:Detail diffslibraries_tests.pmi.windows.x64.checked.mch:Detail diffsAll regressions I checked appear to be of the usual CSE-related flavor.
|
VNForMapStoreSingleAccretion
commented
Nov 21, 2021
@dotnet/jit-contrib |
jakobbotsch
commented
Nov 22, 2021
/azp run Fuzzlyn, runtime-coreclr outerloop |
|
Azure Pipelines successfully started running 2 pipeline(s). |
SingleAccretion
commented
Nov 22, 2021
Fuzzlyn failures appear to be known. The outerloop is almost green... except for one suspicious failure on Looking at the pipeline's recent history, the configuration in question has a higher than average number of failures, but not with these symptoms. It appears the exception is coming from the XUnit process, and that should not be using the runtime under test. So based on that I think it is reasonable to request a retry here and see what happens. |
jakobbotsch
commented
Nov 22, 2021
Done.
There's actually an interesting win x86 failure there, but it's not related to your PR (reproduces on main as well). Been trying to come up with an isolated example that triggers it, but for some reason this is difficult. It reproduces only when executed through Fuzzlyn for some reason. |
SingleAccretion
commented
Nov 22, 2021
Looks like the retry passed. |
jakobbotsch
left a comment
There was a problem hiding this comment.
LGTM, great diffs. Nice work!
Next prerequisite in preparation for typing maps with placeholder types. Separate as there are significant diffs.
First, there is a fix for how type mismatch was accounted for in
fgValueNumberArrIndexAssign- we need to get the type of the last field. Note that at that pointfldSeqonly contains real fields. This fix is needed to minimize diffs for the second change.Which is that we will no longer pass explicit types to
VNForMapStoreand instead derive them frommap, as it reduces the possibility for mismatches and mistakes.There are significant diffs from this, because this way we fix type mismatches arising in code such as the following:
(Struct promotion must be disabled for this sample code)
Previously, when we numbered
a.Index = 1, we gave the whole struct aMapStoreVN ofTYP_INT:This is because
VNApplySelectorsAssigngave the last map it returned a type of the field, which is not correct.This lead to mismatch on copy:
And we lost track of the value. After this change, we no longer do, and this enables some nice improvements.
Win-x64 diffs
benchmarks.run.windows.x64.checked.mch:
Detail diffs
coreclr_tests.pmi.windows.x64.checked.mch:
Detail diffs
libraries.pmi.windows.x64.checked.mch:
Detail diffs
libraries_tests.pmi.windows.x64.checked.mch:
Detail diffs
All regressions I checked appear to be of the usual CSE-related flavor.
Overall diffs.
Part of #58312.