Repository navigation
[JitStress] VectorTableLookupExtension fails in jitstress1 #84696
Description
For:
set DOTNET_TieredCompilation=0
set DOTNET_JitStress=1
We see
14:38:16.844 Running test: _AdvSimd_Arm64_ro::JIT.HardwareIntrinsics.Arm._AdvSimd.Arm64.Program.VectorLookupExtension_2_Byte()
Beginning scenario: RunBasicScenario_UnsafeRead
Arm64.VectorTableLookupExtension<Byte>(Vector128<Byte>, (Vector128<Byte>, Vector128<Byte>>), Vector128<Byte>): RunBasicScenario_UnsafeRead failed:
defaultValues: (31, 10, 93, 216, 169, 113, 148, 77, 204, 243, 166, 115, 27, 230, 43, 78)
firstOp: (213, 126, 207, 229, 250, 214, 46, 187, 23, 195, 145, 45, 18, 53, 73, 179)
secondOp: (198, 236, 120, 37, 38, 35, 212, 247, 230, 73, 19, 125, 181, 45, 221, 145)
indices: (6, 1, 19, 0, 35, 20, 30, 20, 2, 4, 26, 23, 4, 35, 39, 31)
result: (46, 126, 37, 213, 169, 38, 0, 38, 207, 250, 0, 247, 250, 230, 43, 0)
and
14:40:31.521 Running test: _AdvSimd_ro::JIT.HardwareIntrinsics.Arm._AdvSimd.Program.VectorLookupExtension_3_SByte()
Beginning scenario: RunBasicScenario_UnsafeRead
AdvSimd.VectorTableLookupExtension<SByte>(Vector64<SByte>, (Vector128<SByte>, Vector128<SByte>, Vector128<SByte>), Vector64<SByte>): RunBasicScenario_UnsafeRead failed:
defaultValues: (126, 61, 97, 86, 65, 115, 19, 72)
firstOp: (50, 13, 101, 20, 25, 90, 52, 33, 89, 27, 13, 109, 110, 112, 63, 98)
secondOp: (122, 101, 116, 73, 82, 67, 54, 84, 40, 24, 93, 83, 77, 8, 37, 50)
thirdOp: (33, 79, 16, 13, 33, 72, 74, 123, 89, 26, 63, 115, 96, 15, 59, 32)
indices: (44, 36, 7, 43, 4, 12, 56, 11)
result: (0, 33, 33, 0, 25, 0, 19, 0)
Activity
tannergooding commentedon Apr 12, 2023
CC. @kunalspathak
kunalspathak commentedon Apr 12, 2023
Thanks, I will take a look. Most likely this is happening because delay reg frees are not getting tracked properly.
kunalspathak commentedon Apr 13, 2023
Looking at the result and inferring, it seems that the input operand's vector register's upper half are zeroed out. With that only indices between
0 ~ 7and16 ~ 23are returning correct result while other inbound indices are returning0. Out of bound indices are still correct and returns the correct value. Seems something corrupts the input registers during upper vector restore. Will continue investigation.kunalspathak commentedon Apr 13, 2023
Pasting the assembly here.
v17andv18are the table registers and are copied fromv10andv12respectively whose upper-half was restored in the past.Assembly
kunalspathak commentedon Apr 14, 2023
This seems to be an odd existing problem that was surfaced with the consecutive work because this is the first time that we started using
FieldList()for non-call nodes.For
tableoperand ofVectorTableLookup()we createFIELD_LISTto represent it. The actual rows (or vectors) goes inside theFIELD_LIST. Below,[000476]and[000494]are 2 vectors that build the[000333]field list. The field list is used as operand of intrinsic node[000331]. However, between the definition of field list ([000333]) and actual use of it (``[000331]), there are various nodes, including a CALL node[000337]` .When we build
RefPositionfor intrinsic node[000331], we might have to buildRefPositionto restore the upper half vectors of those vectors that are part of the field_list. For example, here is the list of refpositions created:#386: Restore upper-half vector for the 1st operand ofVectorTableLookupExtension#387: Actual use of the 1st operand.#388: Restore upper-half vector for the 1st field of our field list which is the 2nd operand ofVectorTableLookupExtension. This basically corresponds to[000476]in the above tree node dump.#389: Actual use of the 1st field of our field list.#390: Restore upper-half vector for the 2nd field of our field list. This basically corresponds to[000494]in the above tree node dump.#391: Actual use of the 2st field of our field list.#392: Actual use of the 3rd operand.#393: Result ofVectorTableLookupExtension.Note that, Refposition
#388corresponds to the use node[000476]and does not correspond to the actual use of field_list[000331]. As a result, when we have to restore the upper-half vector for this value, we end up restoring it before[000476]. Likewise, it happens for#390, whose upper half vector restore happens at[000494]instead of at[000331].This leads to multiple problems, some of them can be seen in this example:
[000476], but did not feel the need to save the upper-half again before theCALLat[000337]. Because of the call, the upper half of the 1st field is wiped out.CALLat[000337], but its restore happens at[000494], which happened to be located before the place where the save happened. Thus, we ended up restoring before even saving the upper half of a vector.Ideally, we need to carry some semantics to tell that for such situations, consider the use as the field_list instead of individual fields use. I will continue investigating if that will help and feasible.
kunalspathak commentedon Apr 15, 2023
I have discovered another problem related to the ordering and seems to be pre-existing for upper vector restore and copy registers. The arrangement of refpositions for consecutive registers exposed it. This will be a long post, but it is worth describing the problem in detail.
Typically, if there is a use of a partially-saved vector (vector whose upper-half was saved before the call), we first restore it and then use it. There arises an interesting scenario in presence of
FIELD_LIST, where we want to use multiple vector registers in succession, and all should be restored before the use (because all the vector registers were partially-spilled). For example, if there were 3 elements in theFIELD_LIST, the allocation ordering is something like this:The way we insert the restores is by appending them one after another before the use tree node, in our case,
FIELD_LISTor theHWINTRINSICnode and end up something like this:Having such arrangement can create problems, but they can get worse and hit easily if we had to add
copyRegsfor each of those variables before use.copyRegshappens if a variable was assigned a register X, but at the current location, we want a different register Y, we need to insert acopy from X to Yto copy the value of variable present in register X into Y before we use the variable value from Y.For above example, imagine for
V07,V08andV11, they were restored into a different register we need to copy them to the appropriate registers before use, we will generatecopyRegsas seen below:Now let's see an example when a problem can arise because of this. Consider the following order in which registers are allocated for set of refpositions.
Below is the pseudo-code of how the code should look like ideally.
However, since we insert restores one after another, we end up with this:
I will check if I can tweak the algorithm to assign the same consecutive register to upper-half positions too, to avoid extra copies. I already added TODO when working on consecutive registers:
runtime/src/coreclr/jit/lsraarm64.cpp
Lines 93 to 96 in 72586a7
Another possibility is (at least for consecutive register scenarios), mark the registers into which we are restoring the values, and that way they will not used while we are processing the refpositions. In above example, we will basically mark r8 and r10 busy and hence r8 won't be selected to "restore from" register of
V11.Other option is to rearrange the restores properly so they happen right before the actual use instead of arranging them next to each other. This seems a viable option, specially for consecutive registers.
kunalspathak commentedon Apr 15, 2023
A snapshot from the Jitdump for one of the example that has problem I described above:
kunalspathak commentedon Apr 20, 2023
Fixed by #84824