Adding support for Vector512 Equals, EqualsAny, op_Equality, and op_Inequality.

[anthonycanino]

This makes progress towards #80814 and lays foundation for the remaining Vector512 comparison operators.

[ghost]

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

Issue Details

---

DR PR to test Vector512.Equals, Vector512 operator == and Vector512 operator !=.

Author:	anthonycanino
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[anthonycanino]

@dotnet/avx512-contrib

[anthonycanino]

@tannergooding looks like all checks passing

[tannergooding]

Don't expect you to do this here, since this is consistent with the other methods.

But I think we can in general simplify this and several of the other SIMD only flags to something like:

insFlags flags = CodeGenInterface::instInfo[ins];
if ((flags & INS_Flags_Is3OperandInstructionMask) != 0)
{
assert(UseSimdEncoding());
return true;
}
return false;

The UseSimdEncoding() is itself a flag check now and we should never be setting these SIMD only flags on non-SIMD instructions.

[tannergooding]

I'll log an issue for us to look at that as a cleanup item in some follow up PR.

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for
eax, esp are set in regMaskTP

this is then used to set preference incorrectly

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for eax, esp are set in regMaskTP

this is then used to set preference incorrectly

I think I got it. There was a pre-existing bug -

runtime/src/coreclr/jit/targetx86.h

Line 96 in b1812ef

#defineRBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

[DeepakRajendrakumaran]

@tannergooding I've rebased the branch to main and pushed a small fix

[tannergooding]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

I'm having trouble reproducing this
(AnthonyEq_PR

Steps I followed

build.cmd clr+libs -rc Debug -lc release
src\tests\build.cmd x64 debug -priority=1 tree JIT\Performance\CodeQuality\
set DOTNET_TieredCompilation=0
set DOTNET_JitStressEvexEncoding=1
src\tests\run.cmd x64 debug

Also tried just the test highlighed
artifacts\tests\coreclr\windows.x64.Debug\JIT\Performance\CodeQuality\SIMD\SeekUnroll\SeekUnroll\SeekUnroll.cmd

EDIT ; Got it now after rebuilding everything.

@tannergooding Any idea what I'm doing wrong? I pulled from the PR separately as well

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

@tannergooding This is incorrect I think -

runtime/src/coreclr/jit/instrsxarch.h

Line 622 in 0760f77

INST3(vextracti64x4, "extracti64x4", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x3B), INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed quadword integer values

I think it needs to be
INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX)

[tannergooding]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

[DeepakRajendrakumaran]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

Don't think it needs INS_Flags_IsDstDstSrcAVXInstruction either
I added the change to my PR since some tests were failing

[tannergooding]

Resolved the merge conflicts from the narrow/widen and addition/subtraction PRs that got merged

[tannergooding]

SPMI Replay failure is #84536

[DeepakRajendrakumaran]

@BruceForstall Do you think this is good to go or does this need any changes?

[tannergooding]

There's a new merge conflict that needs to be resolved (caused by #84212). We no longer need to pass around isSimdAsHWIntrinsic anymore.

[tannergooding]

SPMI failure is #84536

[anthonycanino]

This makes progress towards #80814 and lays foundation for the remaining Vector512 comparison operators.

[ghost]

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

Issue Details

---

DR PR to test Vector512.Equals, Vector512 operator == and Vector512 operator !=.

Author:	anthonycanino
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[anthonycanino]

@dotnet/avx512-contrib

[anthonycanino]

@tannergooding looks like all checks passing

[tannergooding]

Don't expect you to do this here, since this is consistent with the other methods.

But I think we can in general simplify this and several of the other SIMD only flags to something like:

insFlags flags = CodeGenInterface::instInfo[ins];
if ((flags & INS_Flags_Is3OperandInstructionMask) != 0)
{
assert(UseSimdEncoding());
return true;
}
return false;

The UseSimdEncoding() is itself a flag check now and we should never be setting these SIMD only flags on non-SIMD instructions.

[tannergooding]

I'll log an issue for us to look at that as a cleanup item in some follow up PR.

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for
eax, esp are set in regMaskTP

this is then used to set preference incorrectly

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for eax, esp are set in regMaskTP

this is then used to set preference incorrectly

I think I got it. There was a pre-existing bug -

runtime/src/coreclr/jit/targetx86.h

Line 96 in b1812ef

#defineRBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

[DeepakRajendrakumaran]

@tannergooding I've rebased the branch to main and pushed a small fix

[tannergooding]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

I'm having trouble reproducing this
(AnthonyEq_PR

Steps I followed

build.cmd clr+libs -rc Debug -lc release
src\tests\build.cmd x64 debug -priority=1 tree JIT\Performance\CodeQuality\
set DOTNET_TieredCompilation=0
set DOTNET_JitStressEvexEncoding=1
src\tests\run.cmd x64 debug

Also tried just the test highlighed
artifacts\tests\coreclr\windows.x64.Debug\JIT\Performance\CodeQuality\SIMD\SeekUnroll\SeekUnroll\SeekUnroll.cmd

EDIT ; Got it now after rebuilding everything.

@tannergooding Any idea what I'm doing wrong? I pulled from the PR separately as well

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

@tannergooding This is incorrect I think -

runtime/src/coreclr/jit/instrsxarch.h

Line 622 in 0760f77

INST3(vextracti64x4, "extracti64x4", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x3B), INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed quadword integer values

I think it needs to be
INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX)

[tannergooding]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

[DeepakRajendrakumaran]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

Don't think it needs INS_Flags_IsDstDstSrcAVXInstruction either
I added the change to my PR since some tests were failing

[tannergooding]

Resolved the merge conflicts from the narrow/widen and addition/subtraction PRs that got merged

[tannergooding]

SPMI Replay failure is #84536

[DeepakRajendrakumaran]

@BruceForstall Do you think this is good to go or does this need any changes?

[tannergooding]

There's a new merge conflict that needs to be resolved (caused by #84212). We no longer need to pass around isSimdAsHWIntrinsic anymore.

[tannergooding]

SPMI failure is #84536

[anthonycanino]

This makes progress towards #80814 and lays foundation for the remaining Vector512 comparison operators.

[ghost]

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

Issue Details

---

DR PR to test Vector512.Equals, Vector512 operator == and Vector512 operator !=.

Author:	anthonycanino
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[anthonycanino]

@dotnet/avx512-contrib

[anthonycanino]

@tannergooding looks like all checks passing

[tannergooding]

Don't expect you to do this here, since this is consistent with the other methods.

But I think we can in general simplify this and several of the other SIMD only flags to something like:

insFlags flags = CodeGenInterface::instInfo[ins];
if ((flags & INS_Flags_Is3OperandInstructionMask) != 0)
{
assert(UseSimdEncoding());
return true;
}
return false;

The UseSimdEncoding() is itself a flag check now and we should never be setting these SIMD only flags on non-SIMD instructions.

[tannergooding]

I'll log an issue for us to look at that as a cleanup item in some follow up PR.

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for
eax, esp are set in regMaskTP

this is then used to set preference incorrectly

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for eax, esp are set in regMaskTP

this is then used to set preference incorrectly

I think I got it. There was a pre-existing bug -

runtime/src/coreclr/jit/targetx86.h

Line 96 in b1812ef

#defineRBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

[DeepakRajendrakumaran]

@tannergooding I've rebased the branch to main and pushed a small fix

[tannergooding]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

I'm having trouble reproducing this
(AnthonyEq_PR

Steps I followed

build.cmd clr+libs -rc Debug -lc release
src\tests\build.cmd x64 debug -priority=1 tree JIT\Performance\CodeQuality\
set DOTNET_TieredCompilation=0
set DOTNET_JitStressEvexEncoding=1
src\tests\run.cmd x64 debug

Also tried just the test highlighed
artifacts\tests\coreclr\windows.x64.Debug\JIT\Performance\CodeQuality\SIMD\SeekUnroll\SeekUnroll\SeekUnroll.cmd

EDIT ; Got it now after rebuilding everything.

@tannergooding Any idea what I'm doing wrong? I pulled from the PR separately as well

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

@tannergooding This is incorrect I think -

runtime/src/coreclr/jit/instrsxarch.h

Line 622 in 0760f77

INST3(vextracti64x4, "extracti64x4", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x3B), INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed quadword integer values

I think it needs to be
INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX)

[tannergooding]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

[DeepakRajendrakumaran]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

Don't think it needs INS_Flags_IsDstDstSrcAVXInstruction either
I added the change to my PR since some tests were failing

[tannergooding]

Resolved the merge conflicts from the narrow/widen and addition/subtraction PRs that got merged

[tannergooding]

SPMI Replay failure is #84536

[DeepakRajendrakumaran]

@BruceForstall Do you think this is good to go or does this need any changes?

[tannergooding]

There's a new merge conflict that needs to be resolved (caused by #84212). We no longer need to pass around isSimdAsHWIntrinsic anymore.

[tannergooding]

SPMI failure is #84536

[anthonycanino]

This makes progress towards #80814 and lays foundation for the remaining Vector512 comparison operators.

[ghost]

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

Issue Details

---

DR PR to test Vector512.Equals, Vector512 operator == and Vector512 operator !=.

Author:	anthonycanino
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[anthonycanino]

@dotnet/avx512-contrib

[anthonycanino]

@tannergooding looks like all checks passing

[tannergooding]

Don't expect you to do this here, since this is consistent with the other methods.

But I think we can in general simplify this and several of the other SIMD only flags to something like:

insFlags flags = CodeGenInterface::instInfo[ins];
if ((flags & INS_Flags_Is3OperandInstructionMask) != 0)
{
assert(UseSimdEncoding());
return true;
}
return false;

The UseSimdEncoding() is itself a flag check now and we should never be setting these SIMD only flags on non-SIMD instructions.

[tannergooding]

I'll log an issue for us to look at that as a cleanup item in some follow up PR.

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for
eax, esp are set in regMaskTP

this is then used to set preference incorrectly

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for eax, esp are set in regMaskTP

this is then used to set preference incorrectly

I think I got it. There was a pre-existing bug -

runtime/src/coreclr/jit/targetx86.h

Line 96 in b1812ef

#defineRBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

[DeepakRajendrakumaran]

@tannergooding I've rebased the branch to main and pushed a small fix

[tannergooding]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

I'm having trouble reproducing this
(AnthonyEq_PR

Steps I followed

build.cmd clr+libs -rc Debug -lc release
src\tests\build.cmd x64 debug -priority=1 tree JIT\Performance\CodeQuality\
set DOTNET_TieredCompilation=0
set DOTNET_JitStressEvexEncoding=1
src\tests\run.cmd x64 debug

Also tried just the test highlighed
artifacts\tests\coreclr\windows.x64.Debug\JIT\Performance\CodeQuality\SIMD\SeekUnroll\SeekUnroll\SeekUnroll.cmd

EDIT ; Got it now after rebuilding everything.

@tannergooding Any idea what I'm doing wrong? I pulled from the PR separately as well

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

@tannergooding This is incorrect I think -

runtime/src/coreclr/jit/instrsxarch.h

Line 622 in 0760f77

INST3(vextracti64x4, "extracti64x4", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x3B), INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed quadword integer values

I think it needs to be
INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX)

[tannergooding]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

[DeepakRajendrakumaran]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

Don't think it needs INS_Flags_IsDstDstSrcAVXInstruction either
I added the change to my PR since some tests were failing

[tannergooding]

Resolved the merge conflicts from the narrow/widen and addition/subtraction PRs that got merged

[tannergooding]

SPMI Replay failure is #84536

[DeepakRajendrakumaran]

@BruceForstall Do you think this is good to go or does this need any changes?

[tannergooding]

There's a new merge conflict that needs to be resolved (caused by #84212). We no longer need to pass around isSimdAsHWIntrinsic anymore.

[tannergooding]

SPMI failure is #84536

[anthonycanino]

This makes progress towards #80814 and lays foundation for the remaining Vector512 comparison operators.

[ghost]

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

Issue Details

---

DR PR to test Vector512.Equals, Vector512 operator == and Vector512 operator !=.

Author:	anthonycanino
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[anthonycanino]

@dotnet/avx512-contrib

[anthonycanino]

@tannergooding looks like all checks passing

[tannergooding]

Don't expect you to do this here, since this is consistent with the other methods.

But I think we can in general simplify this and several of the other SIMD only flags to something like:

insFlags flags = CodeGenInterface::instInfo[ins];
if ((flags & INS_Flags_Is3OperandInstructionMask) != 0)
{
assert(UseSimdEncoding());
return true;
}
return false;

The UseSimdEncoding() is itself a flag check now and we should never be setting these SIMD only flags on non-SIMD instructions.

[tannergooding]

I'll log an issue for us to look at that as a cleanup item in some follow up PR.

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for
eax, esp are set in regMaskTP

this is then used to set preference incorrectly

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for eax, esp are set in regMaskTP

this is then used to set preference incorrectly

I think I got it. There was a pre-existing bug -

runtime/src/coreclr/jit/targetx86.h

Line 96 in b1812ef

#defineRBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

[DeepakRajendrakumaran]

@tannergooding I've rebased the branch to main and pushed a small fix

[tannergooding]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

I'm having trouble reproducing this
(AnthonyEq_PR

Steps I followed

build.cmd clr+libs -rc Debug -lc release
src\tests\build.cmd x64 debug -priority=1 tree JIT\Performance\CodeQuality\
set DOTNET_TieredCompilation=0
set DOTNET_JitStressEvexEncoding=1
src\tests\run.cmd x64 debug

Also tried just the test highlighed
artifacts\tests\coreclr\windows.x64.Debug\JIT\Performance\CodeQuality\SIMD\SeekUnroll\SeekUnroll\SeekUnroll.cmd

EDIT ; Got it now after rebuilding everything.

@tannergooding Any idea what I'm doing wrong? I pulled from the PR separately as well

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

@tannergooding This is incorrect I think -

runtime/src/coreclr/jit/instrsxarch.h

Line 622 in 0760f77

INST3(vextracti64x4, "extracti64x4", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x3B), INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed quadword integer values

I think it needs to be
INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX)

[tannergooding]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

[DeepakRajendrakumaran]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

Don't think it needs INS_Flags_IsDstDstSrcAVXInstruction either
I added the change to my PR since some tests were failing

[tannergooding]

Resolved the merge conflicts from the narrow/widen and addition/subtraction PRs that got merged

[tannergooding]

SPMI Replay failure is #84536

[DeepakRajendrakumaran]

@BruceForstall Do you think this is good to go or does this need any changes?

[tannergooding]

There's a new merge conflict that needs to be resolved (caused by #84212). We no longer need to pass around isSimdAsHWIntrinsic anymore.

[tannergooding]

SPMI failure is #84536

[anthonycanino]

This makes progress towards #80814 and lays foundation for the remaining Vector512 comparison operators.

[ghost]

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

Issue Details

---

DR PR to test Vector512.Equals, Vector512 operator == and Vector512 operator !=.

Author:	anthonycanino
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[anthonycanino]

@dotnet/avx512-contrib

[anthonycanino]

@tannergooding looks like all checks passing

[tannergooding]

Don't expect you to do this here, since this is consistent with the other methods.

But I think we can in general simplify this and several of the other SIMD only flags to something like:

insFlags flags = CodeGenInterface::instInfo[ins];
if ((flags & INS_Flags_Is3OperandInstructionMask) != 0)
{
assert(UseSimdEncoding());
return true;
}
return false;

The UseSimdEncoding() is itself a flag check now and we should never be setting these SIMD only flags on non-SIMD instructions.

[tannergooding]

I'll log an issue for us to look at that as a cleanup item in some follow up PR.

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for
eax, esp are set in regMaskTP

this is then used to set preference incorrectly

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for eax, esp are set in regMaskTP

this is then used to set preference incorrectly

I think I got it. There was a pre-existing bug -

runtime/src/coreclr/jit/targetx86.h

Line 96 in b1812ef

#defineRBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

[DeepakRajendrakumaran]

@tannergooding I've rebased the branch to main and pushed a small fix

[tannergooding]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

I'm having trouble reproducing this
(AnthonyEq_PR

Steps I followed

build.cmd clr+libs -rc Debug -lc release
src\tests\build.cmd x64 debug -priority=1 tree JIT\Performance\CodeQuality\
set DOTNET_TieredCompilation=0
set DOTNET_JitStressEvexEncoding=1
src\tests\run.cmd x64 debug

Also tried just the test highlighed
artifacts\tests\coreclr\windows.x64.Debug\JIT\Performance\CodeQuality\SIMD\SeekUnroll\SeekUnroll\SeekUnroll.cmd

EDIT ; Got it now after rebuilding everything.

@tannergooding Any idea what I'm doing wrong? I pulled from the PR separately as well

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

@tannergooding This is incorrect I think -

runtime/src/coreclr/jit/instrsxarch.h

Line 622 in 0760f77

INST3(vextracti64x4, "extracti64x4", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x3B), INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed quadword integer values

I think it needs to be
INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX)

[tannergooding]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

[DeepakRajendrakumaran]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

Don't think it needs INS_Flags_IsDstDstSrcAVXInstruction either
I added the change to my PR since some tests were failing

[tannergooding]

Resolved the merge conflicts from the narrow/widen and addition/subtraction PRs that got merged

[tannergooding]

SPMI Replay failure is #84536

[DeepakRajendrakumaran]

@BruceForstall Do you think this is good to go or does this need any changes?

[tannergooding]

There's a new merge conflict that needs to be resolved (caused by #84212). We no longer need to pass around isSimdAsHWIntrinsic anymore.

[tannergooding]

SPMI failure is #84536

[anthonycanino]

This makes progress towards #80814 and lays foundation for the remaining Vector512 comparison operators.

[ghost]

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

Issue Details

---

DR PR to test Vector512.Equals, Vector512 operator == and Vector512 operator !=.

Author:	anthonycanino
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[anthonycanino]

@dotnet/avx512-contrib

[anthonycanino]

@tannergooding looks like all checks passing

[tannergooding]

Don't expect you to do this here, since this is consistent with the other methods.

But I think we can in general simplify this and several of the other SIMD only flags to something like:

insFlags flags = CodeGenInterface::instInfo[ins];
if ((flags & INS_Flags_Is3OperandInstructionMask) != 0)
{
assert(UseSimdEncoding());
return true;
}
return false;

The UseSimdEncoding() is itself a flag check now and we should never be setting these SIMD only flags on non-SIMD instructions.

[tannergooding]

I'll log an issue for us to look at that as a cleanup item in some follow up PR.

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for
eax, esp are set in regMaskTP

this is then used to set preference incorrectly

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for eax, esp are set in regMaskTP

this is then used to set preference incorrectly

I think I got it. There was a pre-existing bug -

runtime/src/coreclr/jit/targetx86.h

Line 96 in b1812ef

#defineRBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

[DeepakRajendrakumaran]

@tannergooding I've rebased the branch to main and pushed a small fix

[tannergooding]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

I'm having trouble reproducing this
(AnthonyEq_PR

Steps I followed

build.cmd clr+libs -rc Debug -lc release
src\tests\build.cmd x64 debug -priority=1 tree JIT\Performance\CodeQuality\
set DOTNET_TieredCompilation=0
set DOTNET_JitStressEvexEncoding=1
src\tests\run.cmd x64 debug

Also tried just the test highlighed
artifacts\tests\coreclr\windows.x64.Debug\JIT\Performance\CodeQuality\SIMD\SeekUnroll\SeekUnroll\SeekUnroll.cmd

EDIT ; Got it now after rebuilding everything.

@tannergooding Any idea what I'm doing wrong? I pulled from the PR separately as well

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

@tannergooding This is incorrect I think -

runtime/src/coreclr/jit/instrsxarch.h

Line 622 in 0760f77

INST3(vextracti64x4, "extracti64x4", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x3B), INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed quadword integer values

I think it needs to be
INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX)

[tannergooding]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

[DeepakRajendrakumaran]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

Don't think it needs INS_Flags_IsDstDstSrcAVXInstruction either
I added the change to my PR since some tests were failing

[tannergooding]

Resolved the merge conflicts from the narrow/widen and addition/subtraction PRs that got merged

[tannergooding]

SPMI Replay failure is #84536

[DeepakRajendrakumaran]

@BruceForstall Do you think this is good to go or does this need any changes?

[tannergooding]

There's a new merge conflict that needs to be resolved (caused by #84212). We no longer need to pass around isSimdAsHWIntrinsic anymore.

[tannergooding]

SPMI failure is #84536

[anthonycanino]

This makes progress towards #80814 and lays foundation for the remaining Vector512 comparison operators.

[ghost]

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

Issue Details

---

DR PR to test Vector512.Equals, Vector512 operator == and Vector512 operator !=.

Author:	anthonycanino
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[anthonycanino]

@dotnet/avx512-contrib

[anthonycanino]

@tannergooding looks like all checks passing

[tannergooding]

Don't expect you to do this here, since this is consistent with the other methods.

But I think we can in general simplify this and several of the other SIMD only flags to something like:

insFlags flags = CodeGenInterface::instInfo[ins];
if ((flags & INS_Flags_Is3OperandInstructionMask) != 0)
{
assert(UseSimdEncoding());
return true;
}
return false;

The UseSimdEncoding() is itself a flag check now and we should never be setting these SIMD only flags on non-SIMD instructions.

[tannergooding]

I'll log an issue for us to look at that as a cleanup item in some follow up PR.

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for
eax, esp are set in regMaskTP

this is then used to set preference incorrectly

[DeepakRajendrakumaran]

There's some conflicts that need to be resolved, but the changes otherwise LGTM.

I haven't rebased to latest main. The current version has some failures on x86 where eax,ecx(non k registers) are identified as 'preferred registers' for mask. This causes an assert. As far as I can tell, something seem to be off with the populated 'availableRegs' I'll rebase this branch to main and check again

I checked again. It still fails. Looks like we are initializing availableMaskRegs incorrectly for some reason. For TYP_MASK, the following returns back 17 which means bits for eax, esp are set in regMaskTP

this is then used to set preference incorrectly

I think I got it. There was a pre-existing bug -

runtime/src/coreclr/jit/targetx86.h

Line 96 in b1812ef

#defineRBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

[DeepakRajendrakumaran]

@tannergooding I've rebased the branch to main and pushed a small fix

[tannergooding]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

I'm having trouble reproducing this
(AnthonyEq_PR

Steps I followed

build.cmd clr+libs -rc Debug -lc release
src\tests\build.cmd x64 debug -priority=1 tree JIT\Performance\CodeQuality\
set DOTNET_TieredCompilation=0
set DOTNET_JitStressEvexEncoding=1
src\tests\run.cmd x64 debug

Also tried just the test highlighed
artifacts\tests\coreclr\windows.x64.Debug\JIT\Performance\CodeQuality\SIMD\SeekUnroll\SeekUnroll\SeekUnroll.cmd

EDIT ; Got it now after rebuilding everything.

@tannergooding Any idea what I'm doing wrong? I pulled from the PR separately as well

[DeepakRajendrakumaran]

Seems there is a new assert where some BMI1/2 instruction is hitting the EVEX encoding path.

@tannergooding This is incorrect I think -

runtime/src/coreclr/jit/instrsxarch.h

Line 622 in 0760f77

INST3(vextracti64x4, "extracti64x4", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x3B), INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed quadword integer values

I think it needs to be
INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX)

[tannergooding]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

[DeepakRajendrakumaran]

Ah, yeah. extract needs to have its encoding in the MR column, not in the RM column.

That would need to be fixed for extracti and extractf for 64x4 and 32x8

Don't think it needs INS_Flags_IsDstDstSrcAVXInstruction either
I added the change to my PR since some tests were failing

[tannergooding]

Resolved the merge conflicts from the narrow/widen and addition/subtraction PRs that got merged

[tannergooding]

SPMI Replay failure is #84536

[DeepakRajendrakumaran]

@BruceForstall Do you think this is good to go or does this need any changes?

[tannergooding]

There's a new merge conflict that needs to be resolved (caused by #84212). We no longer need to pass around isSimdAsHWIntrinsic anymore.

[tannergooding]

SPMI failure is #84536