Assertion failed '(consume == 0) || (ComputeAvailableSrcCount(tree) == consume)'

[EgorBo]

Compile the following method with Checked JIT:

public bool EqualsTest(byte* a, byte* b, nuint len)
{
    for (nuint i = 0; i < len; i += 128)
    {
        var v11 = Vector512.LoadAligned(a + i);
        var v12 = Vector512.LoadAligned(a + i + 64);
        var v21 = Vector512.LoadAligned(b + i);
        var v22 = Vector512.LoadAligned(b + i + 64);
        if (((v11 ^ v21) | (v12 ^ v22)) != Vector512<byte>.Zero)
            return false;
    }
    return false;
}

Expected: compiles
Actual:

Assert failure(PID 374500 [0x0005b6e4], Thread: 444996 [0x6ca44]): Assertion failed '(consume == 0) || (ComputeAvailableSrcCount(tree) == consume)' in 'Benchmarks:EqualsTest(ulong,ulong,ulong):ubyte:this' during 'Linear scan register alloc' (IL size 105; hash 0x96711b35; FullOpts)

    File: C:\prj\runtime-main\src\coreclr\jit\lsrabuild.cpp:1775
    Image: C:\prj\runtime-main\artifacts\bin\coreclr\windows.x64.Checked\CoreRun.exe

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[JulieLeeMSFT]

@kunalspathak, PTAL.

[kunalspathak]

For TernaryLogic node [000039], we have its child node t24 marked as contained and also the child node t23 of t24. The assert is mainly because when we create RefPositions, we end up just creating 2 refpositions for [000039] (for t10 and t38) and do not generate for t24 and t71 (because they are contained). Later, we check in ComputeAvailableSrcCount(tree) if the number of refpositions created match and in that method, we count the as if the refpositions created for t21 and t22.

However, I think there is some problem in marking the containment of t24 (because I commented out the assert just to see how far it goes along and I hit an assert during codegen for t39. This happens when we try to consume the node t21 which has REG_NA. Is it correct to mark it as contained?

                                                            ┌──▌  t9     long   
N027 (  5,  4) [000010] ---XG+-----                   t10 = ▌  HWINTRINSIC simd64 64 ubyte LoadAlignedVector512 REG mm0 <l:$283, c:$282>
N029 (  1,  1) [000021] -----+-----                   t21 =    LCL_VAR   long   V01 arg1         u:1 rdx REG NA $81
N031 (  1,  1) [000022] -----+-----                   t22 =    LCL_VAR   long   V03 loc0         u:3 rax REG NA $180
                                                            ┌──▌  t21    long   
                                                            ├──▌  t22    long   
N033 (  2,  2) [000023] -c---+-----                   t23 = ▌  LEA(b+(i*1)+0) long   REG NA
                                                            ┌──▌  t23    long   
N035 (  5,  4) [000024] -c-XG+-----                   t24 = ▌  HWINTRINSIC simd64 64 ubyte LoadAlignedVector512 REG NA <l:$287, c:$286>
N037 (  1,  1) [000011] -----+-----                   t11 =    LCL_VAR   long   V00 arg0         u:1 rcx REG rcx $80
N039 (  1,  1) [000012] -----+-----                   t12 =    LCL_VAR   long   V03 loc0         u:3 rax REG rax $180
                                                            ┌──▌  t11    long   
                                                            ├──▌  t12    long   
N041 (  3,  3) [000016] -c---+-----                   t16 = ▌  LEA(b+(i*1)+64) long   REG NA
                                                            ┌──▌  t16    long   
N043 (  5,  5) [000017] ---XG+-----                   t17 = ▌  HWINTRINSIC simd64 64 ubyte LoadAlignedVector512 REG mm1 <l:$28d, c:$28c>
...
...
...
N053 ( 11, 11) [000038] ---XG+-----                   t38 = ▌  HWINTRINSIC simd64 64 uint Xor REG mm1 <l:$293, c:$292>
N055 (???,???) [000071] -c---------                   t71 =    CNS_INT   int    222 REG NA
                                                            ┌──▌  t10    simd64 
                                                            ├──▌  t38    simd64 
                                                            ├──▌  t24    simd64 
                                                            ├──▌  t71    int    
N057 ( 23, 21) [000039] ---XG+-----                   t39 = ▌  HWINTRINSIC simd64 64 uint TernaryLogic REG mm0 <l:$295, c:$294>
                                                            ┌──▌  t39    simd64 
N059 (???,???) [000072] DA-XG------                         ▌  STORE_LCL_VAR simd64 V09 rat0          mm0 REG mm0

@saucecontrol - could this be related to #110736?

Here is the superpmi collection on 60e9340.

consume.zip

[saucecontrol]

It should be fine for t24 to be contained, because the instruction does accept a memory load operand in that position and of that size.

VPTERNLOGD zmm1 {k1}{z}, zmm2, zmm3/m512/m32bcst, imm8)

Looks like an addressing mode isn't handled for that instruction somewhere? I'm afraid I'm not too familiar with the emitter/LSRA side, so I'm not quite sure where to look.

[saucecontrol]

Actually, could it be as simple as this?

runtime/src/coreclr/jit/lsraxarch.cpp

Lines 2900 to 2903 in c048ff0

	if (op2->OperIs(GT_HWINTRINSIC) && op2->AsHWIntrinsic()->OperIsMemoryLoad() && op2->isContained())
	{
	srcCount += BuildAddrUses(op2->AsHWIntrinsic()->Op(1), op2RegCandidates);
	}

It checks for contained HWINTRINSIC nodes in op2 position, but vpternlog would have the contained load in op3, which doesn't have equivalent handling.

[saucecontrol]

Confirmed adding the same handling for op3 fixes it.