Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 18 commits into from
Apr 10, 2023

Conversation

anthonycanino
Copy link
Contributor

@anthonycanino anthonycanino commented Mar 15, 2023

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

@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Mar 15, 2023
@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2023
@ghost
Copy link

ghost commented Mar 15, 2023

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 anthonycanino changed the title Avx512 equality Adding support for Vector512 Equals, op_Equality, and op_Inequality. Mar 16, 2023
@anthonycanino anthonycanino marked this pull request as ready for review March 16, 2023 19:58
@anthonycanino
Copy link
Contributor Author

@dotnet/avx512-contrib

@anthonycanino anthonycanino changed the title Adding support for Vector512 Equals, op_Equality, and op_Inequality. Adding support for Vector512 Equals, EqualsAny, op_Equality, and op_Inequality. Mar 17, 2023
@anthonycanino anthonycanino changed the title Adding support for Vector512 Equals, EqualsAny, op_Equality, and op_Inequality. Adding support for Vector512 Equals, EqualsAny, op_Equality, and op_Inequality. Mar 17, 2023
@anthonycanino
Copy link
Contributor Author

@tannergooding looks like all checks passing

Comment on lines +260 to +261
if (!UseSimdEncoding())
{
return false;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@DeepakRajendrakumaran
Copy link
Contributor

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
Copy link
Contributor

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
image

this is then used to set preference incorrectly

image

@DeepakRajendrakumaran
Copy link
Contributor

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 image

this is then used to set preference incorrectly

image

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

#define RBM_ALLMASK REG_K1

Should have been RBP_K1 Will update after testing

@DeepakRajendrakumaran
Copy link
Contributor

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

@tannergooding
Copy link
Member

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

@DeepakRajendrakumaran
Copy link
Contributor

DeepakRajendrakumaran commented Apr 6, 2023

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
Copy link
Contributor

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

@tannergooding This is incorrect I think -

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
Copy link
Member

tannergooding commented Apr 7, 2023

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
Copy link
Contributor

DeepakRajendrakumaran commented Apr 7, 2023

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
Copy link
Member

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

@tannergooding
Copy link
Member

SPMI Replay failure is #84536

@DeepakRajendrakumaran
Copy link
Contributor

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

@tannergooding
Copy link
Member

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

@tannergooding tannergooding merged commit f211984 into dotnet:main Apr 10, 2023
@tannergooding
Copy link
Member

SPMI failure is #84536

@ghost ghost locked as resolved and limited conversation to collaborators May 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI avx512 Related to the AVX-512 architecture community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants