-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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 CPUID for AVX10.2 #109302
Adding CPUID for AVX10.2 #109302
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
edcaabd
to
a55717e
Compare
fe57968
to
738cff9
Compare
@tannergooding Can you please help review this PR? |
This has conflicts that need resolving now that #104637 is merged |
738cff9
to
e1aa9cf
Compare
@tannergooding PR has been rebased and updated. |
I think we're missing some handling in:
Since we don't have managed ISAs yet we don't need to handle:
|
Thanks for pointing me to this. Looks like this handling was added later to handle |
CC, @dotnet/jit-contrib for secondary review |
@@ -375,6 +375,10 @@ public bool ComputeInstructionSetFlags(int maxVectorTBitWidth, | |||
|
|||
if (_supportedInstructionSets.Contains("avx10v1")) | |||
_supportedInstructionSets.Add("avx10v1_v512"); | |||
|
|||
// Having AVX10V1-V512 enabled, means having AVX10V2-V512 enabled as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this backwards? It seems that if avx10v2_v512 is supported then avx10v1_v512 is also supported, but not vice-versa.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one does look incorrect. I believe it should be if (_supportedInstructionSets.Contains("avx10v2"))
so it matches the AVX10v1 handling just above.
Which is to say that if Avx10v2
is supported and AVX512
is supported, then Avx10v2_V512
is supported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had deliberately kept this as is. By implication
implication ,X86 ,AVX10v2 ,AVX10v1
implication ,X86 ,AVX10v2_V512 ,AVX10v1_V512
And what bruce is saying is correct. If we have AVX10v2_V512
, then we would have AVX10v1_V512
. Please correct me if I am understanding it wrong. From the design, we cannot have AVX10v1
and have AVX10v2
. But to maintain a standard code, I will just change it to what we have for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is doing functionally implication ,X86 ,AVX10v1_V512, AVX10v2_V512
where-as the actual implication is implication ,X86 ,AVX10v2_V512, AVX10v1_V512
. This would result in a machine/target with only AVX10v1 enabling AVX10v2 support.
The way the logic in this function is meant to work is to cover implications that cannot be tracked trivially by the hierarchy, such as enabling AVX10v2.V512
when AVX10v2 + AVX512
is supported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. thanks for pointing this out @BruceForstall @tannergooding
if (resultflags.HasInstructionSet(InstructionSet.X86_AVX10v1)) | ||
resultflags.AddInstructionSet(InstructionSet.X86_AVX10v2); | ||
if (resultflags.HasInstructionSet(InstructionSet.X86_AVX10v1_V512)) | ||
resultflags.AddInstructionSet(InstructionSet.X86_AVX10v2_V512); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems odd: it says that if AVX10v1 is supported, then AVX10v2 is supported. Is that correct? I assume the OPPOSITE is true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is part of ExpandInstructionSetByReverseImplicationHelper
, which exists to allow NAOT to enable any dependent ISAs if the user just specifies avx10v2
on the command line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The opposite is true. @khushal1996 please correct this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anthonycanino this part is correct (and is notably autogenerated by the tool). Its part of ExpandInstructionSetByReverseImplicationHelper
@khushal1996 A change that added another ISA just went in, meaning you need to resolve the merge conflicts in this PR. |
910b644
to
0eaa744
Compare
Overview
This PR tracks addition of CPUID for AVX10.2 to runtime. We are following the spec doc to add the CPUID for AVX10.2. Following things have been modified as a part of this PR
InstructionSet_Avx10v2
andInstructionSet_Avx10v2_V512
EnableAvx10v2
to JIT.EnableAvx10v1
will take priority overEnableAvx10v2
i.e. ifAvx10v1
is disabled,Avx10v2
will be disabled too.Testing Correctness of Logic
Since we don't have the DMR hardware available right now, the testing for this PR was done on internal SDE. Following scenarios were tested on internal SDE
Add debug prints to check the value of
cpufeatures
after setting all the ISA flags.Enable
AVX10v1
andAVX10v2
by default and do the same.Disable
Avx10v1
and check if it disablesAvx10v2
. (it should disableAVX10v2
)Disable
Avx10v2
and verify thatAvx10v1
stays enabled.Testing JIT test suite
The testing was done using the Rex2 unit testing framework. All the changes made for testing CPUID changes are present in this repo
A brief overview -->
dmr
machineStep 1: Run all tests without SDE
Step 2: Running all tests on the current branch with
sde -dmr
andDOTNET_EnableAVX10v2=0
Step 3: Running all tests on the current branch with
sde -dmr
Testing ASMDIFFS
Using
jit-diff
method, this testing step compares assembly between themain
and the current branch and makes sure that we are not changing any existing scenarios.Note - we cannot use superpmi here since we are adding a new CPUID and hence the
jiteeversionguid
has changed which would lead to wrong results from superpmi.