remove unnecessary Avx512VL ISA flags.

[Ruihan-Yin]

More context in #103019 (comment)

To save some space in XArchIntrinsicConstants, this PR turns Avx512*_VL ISA flags per subset into a converged flag: Avx512F_VL, such that we can hold more ISAs within this enum, this will be the pre-work for the ongoing APX project.

[tannergooding]

Can we just have this be Avx512vl, as that's the actual CPUID feature name and matches the casing we use elsewhere?

[Ruihan-Yin]

I agree, will rename this part accordingly.

[tannergooding]

It'd be nice to remove these as well.

The former is unnecessary and the latter is implied by Avx512F existing.

[Ruihan-Yin]

I can make this change, and just make sure, does this part have conflicting changes with the ongoing Avx10 PR? I know some changes happening there for this as well, but didn't follow closely.

[tannergooding]

That PR is removing Avx10v1_v256, so removing it here as well should help avoid a conflict.

[Ruihan-Yin]

I saw Avx10v1_V256 was removed from InstructionSetDesc.txt, so what we want here is don't even define Avx10v1_V256 and Avx10v1_V512, and rely on EVEX to make sure JIT backend will correctly handle Avx10 nodes? Just to confirm.

[tannergooding]

Right. Avx10v1_v256 is just part of Avx10v1, so it's unnecessary.

Likewise, Avx10v1_v512 is really just Avx10v1 + Avx512, so doing those checks instead fits the need and saves us bits.

[Ruihan-Yin]

Thanks for the inputs,

There are duplicated implications there: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetDesc.txt#L141

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

Edit:
If we remove Avx10v1_V512, then the node definitions here might need some refactoring? It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

[tannergooding]

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

No and I'm actually fixing that in #103241

It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

Right, this is what I had meant should happen.

Any refactoring that changes how InstructionSet_* works might be possible but would be a more involved change.

[Ruihan-Yin]

Thanks for the explanation, in that case, I can wait for this PR go in first, and I will handle the conflict accordingly.

[jkotas]

You will also need to fix this to check that all feature bits are present for features described by multiple bits.

[jkotas]

Suggested change

	switch(instructionSet)
	{
	caseInstructionSet.X64_AVX10v1_V512:
	caseInstructionSet.X64_AVX10v1_V512_X64:
	caseInstructionSet.X64_AVX512F_VL:
	caseInstructionSet.X64_AVX512F_VL_X64:
	caseInstructionSet.X64_AVX512BW_VL:
	caseInstructionSet.X64_AVX512BW_VL_X64:
	caseInstructionSet.X64_AVX512CD_VL:
	caseInstructionSet.X64_AVX512CD_VL_X64:
	caseInstructionSet.X64_AVX512DQ_VL:
	caseInstructionSet.X64_AVX512DQ_VL_X64:
	caseInstructionSet.X64_AVX512VBMI_VL:
	caseInstructionSet.X64_AVX512VBMI_VL_X64:
	if(!uint.IsPow2((uint)flag))
	{

You should be able to just check whether the flag has one or more bits.

[jkotas]

Suggested change

	codeStream.Emit(ILOpcode.beq);
	codeStream.Emit(ILOpcode.ceq);

beq is "branch on equal". This is needs to be compare instead.

[Ruihan-Yin]

Corrected, thanks for pointing out!

[Ruihan-Yin]

rebased the branch to resolve conflicts.

I kept Avx10v1_V512 as an ISA to make it consistent with the node definition in hwintrinsicxarchlist.h. If we need further changes, I can try to make it within this PR.

The fails look like connection issue.

[Ruihan-Yin]

Hi @tannergooding,

Just making sure, I am looking at the #103241, in that PR, we have folded all the Avx512 bits into 1, is that expected moving on, or we are still looking for separate them out to be F+VL+BW+CD+DQ as discussed here. If not, I suppose the only thing left for this PR would be removing Avx10v1_V512?

Edit:
Conflicts have been resolved, I have only pushed the changes for Avx10v1 part first. For Avx512, I kept it to what has been changes in #103241, if we want to expand Avx512 flags, I will make the changes accordingly.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[Ruihan-Yin]

Except known failures, the build fail looks like due to timeout, and not related the changes.

[tannergooding]

Rerunning CI to get it in a clean state

[Ruihan-Yin]

Build Analysis has shown green, PR should be in clean state.

[tannergooding]

@jkotas, did you have any other feedback here or can I merge once CI is showing green?

[jkotas]

LGTM

[Ruihan-Yin]

I was not able to reproduce the CI fail locally.

From the call stack, it is more likely to be connection issue.

[Ruihan-Yin]

Thanks for all the suggestions and help!

[Ruihan-Yin]

More context in #103019 (comment)

To save some space in XArchIntrinsicConstants, this PR turns Avx512*_VL ISA flags per subset into a converged flag: Avx512F_VL, such that we can hold more ISAs within this enum, this will be the pre-work for the ongoing APX project.

[tannergooding]

Can we just have this be Avx512vl, as that's the actual CPUID feature name and matches the casing we use elsewhere?

[Ruihan-Yin]

I agree, will rename this part accordingly.

[tannergooding]

It'd be nice to remove these as well.

The former is unnecessary and the latter is implied by Avx512F existing.

[Ruihan-Yin]

I can make this change, and just make sure, does this part have conflicting changes with the ongoing Avx10 PR? I know some changes happening there for this as well, but didn't follow closely.

[tannergooding]

That PR is removing Avx10v1_v256, so removing it here as well should help avoid a conflict.

[Ruihan-Yin]

I saw Avx10v1_V256 was removed from InstructionSetDesc.txt, so what we want here is don't even define Avx10v1_V256 and Avx10v1_V512, and rely on EVEX to make sure JIT backend will correctly handle Avx10 nodes? Just to confirm.

[tannergooding]

Right. Avx10v1_v256 is just part of Avx10v1, so it's unnecessary.

Likewise, Avx10v1_v512 is really just Avx10v1 + Avx512, so doing those checks instead fits the need and saves us bits.

[Ruihan-Yin]

Thanks for the inputs,

There are duplicated implications there: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetDesc.txt#L141

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

Edit:
If we remove Avx10v1_V512, then the node definitions here might need some refactoring? It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

[tannergooding]

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

No and I'm actually fixing that in #103241

It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

Right, this is what I had meant should happen.

Any refactoring that changes how InstructionSet_* works might be possible but would be a more involved change.

[Ruihan-Yin]

Thanks for the explanation, in that case, I can wait for this PR go in first, and I will handle the conflict accordingly.

[jkotas]

You will also need to fix this to check that all feature bits are present for features described by multiple bits.

[jkotas]

Suggested change

	switch(instructionSet)
	{
	caseInstructionSet.X64_AVX10v1_V512:
	caseInstructionSet.X64_AVX10v1_V512_X64:
	caseInstructionSet.X64_AVX512F_VL:
	caseInstructionSet.X64_AVX512F_VL_X64:
	caseInstructionSet.X64_AVX512BW_VL:
	caseInstructionSet.X64_AVX512BW_VL_X64:
	caseInstructionSet.X64_AVX512CD_VL:
	caseInstructionSet.X64_AVX512CD_VL_X64:
	caseInstructionSet.X64_AVX512DQ_VL:
	caseInstructionSet.X64_AVX512DQ_VL_X64:
	caseInstructionSet.X64_AVX512VBMI_VL:
	caseInstructionSet.X64_AVX512VBMI_VL_X64:
	if(!uint.IsPow2((uint)flag))
	{

You should be able to just check whether the flag has one or more bits.

[jkotas]

Suggested change

	codeStream.Emit(ILOpcode.beq);
	codeStream.Emit(ILOpcode.ceq);

beq is "branch on equal". This is needs to be compare instead.

[Ruihan-Yin]

Corrected, thanks for pointing out!

[Ruihan-Yin]

rebased the branch to resolve conflicts.

I kept Avx10v1_V512 as an ISA to make it consistent with the node definition in hwintrinsicxarchlist.h. If we need further changes, I can try to make it within this PR.

The fails look like connection issue.

[Ruihan-Yin]

Hi @tannergooding,

Just making sure, I am looking at the #103241, in that PR, we have folded all the Avx512 bits into 1, is that expected moving on, or we are still looking for separate them out to be F+VL+BW+CD+DQ as discussed here. If not, I suppose the only thing left for this PR would be removing Avx10v1_V512?

Edit:
Conflicts have been resolved, I have only pushed the changes for Avx10v1 part first. For Avx512, I kept it to what has been changes in #103241, if we want to expand Avx512 flags, I will make the changes accordingly.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[Ruihan-Yin]

Except known failures, the build fail looks like due to timeout, and not related the changes.

[tannergooding]

Rerunning CI to get it in a clean state

[Ruihan-Yin]

Build Analysis has shown green, PR should be in clean state.

[tannergooding]

@jkotas, did you have any other feedback here or can I merge once CI is showing green?

[jkotas]

LGTM

[Ruihan-Yin]

I was not able to reproduce the CI fail locally.

From the call stack, it is more likely to be connection issue.

[Ruihan-Yin]

Thanks for all the suggestions and help!

[Ruihan-Yin]

More context in #103019 (comment)

To save some space in XArchIntrinsicConstants, this PR turns Avx512*_VL ISA flags per subset into a converged flag: Avx512F_VL, such that we can hold more ISAs within this enum, this will be the pre-work for the ongoing APX project.

[tannergooding]

Can we just have this be Avx512vl, as that's the actual CPUID feature name and matches the casing we use elsewhere?

[Ruihan-Yin]

I agree, will rename this part accordingly.

[tannergooding]

It'd be nice to remove these as well.

The former is unnecessary and the latter is implied by Avx512F existing.

[Ruihan-Yin]

I can make this change, and just make sure, does this part have conflicting changes with the ongoing Avx10 PR? I know some changes happening there for this as well, but didn't follow closely.

[tannergooding]

That PR is removing Avx10v1_v256, so removing it here as well should help avoid a conflict.

[Ruihan-Yin]

I saw Avx10v1_V256 was removed from InstructionSetDesc.txt, so what we want here is don't even define Avx10v1_V256 and Avx10v1_V512, and rely on EVEX to make sure JIT backend will correctly handle Avx10 nodes? Just to confirm.

[tannergooding]

Right. Avx10v1_v256 is just part of Avx10v1, so it's unnecessary.

Likewise, Avx10v1_v512 is really just Avx10v1 + Avx512, so doing those checks instead fits the need and saves us bits.

[Ruihan-Yin]

Thanks for the inputs,

There are duplicated implications there: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetDesc.txt#L141

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

Edit:
If we remove Avx10v1_V512, then the node definitions here might need some refactoring? It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

[tannergooding]

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

No and I'm actually fixing that in #103241

It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

Right, this is what I had meant should happen.

Any refactoring that changes how InstructionSet_* works might be possible but would be a more involved change.

[Ruihan-Yin]

Thanks for the explanation, in that case, I can wait for this PR go in first, and I will handle the conflict accordingly.

[jkotas]

You will also need to fix this to check that all feature bits are present for features described by multiple bits.

[jkotas]

Suggested change

	switch(instructionSet)
	{
	caseInstructionSet.X64_AVX10v1_V512:
	caseInstructionSet.X64_AVX10v1_V512_X64:
	caseInstructionSet.X64_AVX512F_VL:
	caseInstructionSet.X64_AVX512F_VL_X64:
	caseInstructionSet.X64_AVX512BW_VL:
	caseInstructionSet.X64_AVX512BW_VL_X64:
	caseInstructionSet.X64_AVX512CD_VL:
	caseInstructionSet.X64_AVX512CD_VL_X64:
	caseInstructionSet.X64_AVX512DQ_VL:
	caseInstructionSet.X64_AVX512DQ_VL_X64:
	caseInstructionSet.X64_AVX512VBMI_VL:
	caseInstructionSet.X64_AVX512VBMI_VL_X64:
	if(!uint.IsPow2((uint)flag))
	{

You should be able to just check whether the flag has one or more bits.

[jkotas]

Suggested change

	codeStream.Emit(ILOpcode.beq);
	codeStream.Emit(ILOpcode.ceq);

beq is "branch on equal". This is needs to be compare instead.

[Ruihan-Yin]

Corrected, thanks for pointing out!

[Ruihan-Yin]

rebased the branch to resolve conflicts.

I kept Avx10v1_V512 as an ISA to make it consistent with the node definition in hwintrinsicxarchlist.h. If we need further changes, I can try to make it within this PR.

The fails look like connection issue.

[Ruihan-Yin]

Hi @tannergooding,

Just making sure, I am looking at the #103241, in that PR, we have folded all the Avx512 bits into 1, is that expected moving on, or we are still looking for separate them out to be F+VL+BW+CD+DQ as discussed here. If not, I suppose the only thing left for this PR would be removing Avx10v1_V512?

Edit:
Conflicts have been resolved, I have only pushed the changes for Avx10v1 part first. For Avx512, I kept it to what has been changes in #103241, if we want to expand Avx512 flags, I will make the changes accordingly.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[Ruihan-Yin]

Except known failures, the build fail looks like due to timeout, and not related the changes.

[tannergooding]

Rerunning CI to get it in a clean state

[Ruihan-Yin]

Build Analysis has shown green, PR should be in clean state.

[tannergooding]

@jkotas, did you have any other feedback here or can I merge once CI is showing green?

[jkotas]

LGTM

[Ruihan-Yin]

I was not able to reproduce the CI fail locally.

From the call stack, it is more likely to be connection issue.

[Ruihan-Yin]

Thanks for all the suggestions and help!

[Ruihan-Yin]

More context in #103019 (comment)

To save some space in XArchIntrinsicConstants, this PR turns Avx512*_VL ISA flags per subset into a converged flag: Avx512F_VL, such that we can hold more ISAs within this enum, this will be the pre-work for the ongoing APX project.

[tannergooding]

Can we just have this be Avx512vl, as that's the actual CPUID feature name and matches the casing we use elsewhere?

[Ruihan-Yin]

I agree, will rename this part accordingly.

[tannergooding]

It'd be nice to remove these as well.

The former is unnecessary and the latter is implied by Avx512F existing.

[Ruihan-Yin]

I can make this change, and just make sure, does this part have conflicting changes with the ongoing Avx10 PR? I know some changes happening there for this as well, but didn't follow closely.

[tannergooding]

That PR is removing Avx10v1_v256, so removing it here as well should help avoid a conflict.

[Ruihan-Yin]

I saw Avx10v1_V256 was removed from InstructionSetDesc.txt, so what we want here is don't even define Avx10v1_V256 and Avx10v1_V512, and rely on EVEX to make sure JIT backend will correctly handle Avx10 nodes? Just to confirm.

[tannergooding]

Right. Avx10v1_v256 is just part of Avx10v1, so it's unnecessary.

Likewise, Avx10v1_v512 is really just Avx10v1 + Avx512, so doing those checks instead fits the need and saves us bits.

[Ruihan-Yin]

Thanks for the inputs,

There are duplicated implications there: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetDesc.txt#L141

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

Edit:
If we remove Avx10v1_V512, then the node definitions here might need some refactoring? It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

[tannergooding]

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

No and I'm actually fixing that in #103241

It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

Right, this is what I had meant should happen.

Any refactoring that changes how InstructionSet_* works might be possible but would be a more involved change.

[Ruihan-Yin]

Thanks for the explanation, in that case, I can wait for this PR go in first, and I will handle the conflict accordingly.

[jkotas]

You will also need to fix this to check that all feature bits are present for features described by multiple bits.

[jkotas]

Suggested change

	switch(instructionSet)
	{
	caseInstructionSet.X64_AVX10v1_V512:
	caseInstructionSet.X64_AVX10v1_V512_X64:
	caseInstructionSet.X64_AVX512F_VL:
	caseInstructionSet.X64_AVX512F_VL_X64:
	caseInstructionSet.X64_AVX512BW_VL:
	caseInstructionSet.X64_AVX512BW_VL_X64:
	caseInstructionSet.X64_AVX512CD_VL:
	caseInstructionSet.X64_AVX512CD_VL_X64:
	caseInstructionSet.X64_AVX512DQ_VL:
	caseInstructionSet.X64_AVX512DQ_VL_X64:
	caseInstructionSet.X64_AVX512VBMI_VL:
	caseInstructionSet.X64_AVX512VBMI_VL_X64:
	if(!uint.IsPow2((uint)flag))
	{

You should be able to just check whether the flag has one or more bits.

[jkotas]

Suggested change

	codeStream.Emit(ILOpcode.beq);
	codeStream.Emit(ILOpcode.ceq);

beq is "branch on equal". This is needs to be compare instead.

[Ruihan-Yin]

Corrected, thanks for pointing out!

[Ruihan-Yin]

rebased the branch to resolve conflicts.

I kept Avx10v1_V512 as an ISA to make it consistent with the node definition in hwintrinsicxarchlist.h. If we need further changes, I can try to make it within this PR.

The fails look like connection issue.

[Ruihan-Yin]

Hi @tannergooding,

Just making sure, I am looking at the #103241, in that PR, we have folded all the Avx512 bits into 1, is that expected moving on, or we are still looking for separate them out to be F+VL+BW+CD+DQ as discussed here. If not, I suppose the only thing left for this PR would be removing Avx10v1_V512?

Edit:
Conflicts have been resolved, I have only pushed the changes for Avx10v1 part first. For Avx512, I kept it to what has been changes in #103241, if we want to expand Avx512 flags, I will make the changes accordingly.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[Ruihan-Yin]

Except known failures, the build fail looks like due to timeout, and not related the changes.

[tannergooding]

Rerunning CI to get it in a clean state

[Ruihan-Yin]

Build Analysis has shown green, PR should be in clean state.

[tannergooding]

@jkotas, did you have any other feedback here or can I merge once CI is showing green?

[jkotas]

LGTM

[Ruihan-Yin]

I was not able to reproduce the CI fail locally.

From the call stack, it is more likely to be connection issue.

[Ruihan-Yin]

Thanks for all the suggestions and help!

[Ruihan-Yin]

More context in #103019 (comment)

To save some space in XArchIntrinsicConstants, this PR turns Avx512*_VL ISA flags per subset into a converged flag: Avx512F_VL, such that we can hold more ISAs within this enum, this will be the pre-work for the ongoing APX project.

[tannergooding]

Can we just have this be Avx512vl, as that's the actual CPUID feature name and matches the casing we use elsewhere?

[Ruihan-Yin]

I agree, will rename this part accordingly.

[tannergooding]

It'd be nice to remove these as well.

The former is unnecessary and the latter is implied by Avx512F existing.

[Ruihan-Yin]

I can make this change, and just make sure, does this part have conflicting changes with the ongoing Avx10 PR? I know some changes happening there for this as well, but didn't follow closely.

[tannergooding]

That PR is removing Avx10v1_v256, so removing it here as well should help avoid a conflict.

[Ruihan-Yin]

I saw Avx10v1_V256 was removed from InstructionSetDesc.txt, so what we want here is don't even define Avx10v1_V256 and Avx10v1_V512, and rely on EVEX to make sure JIT backend will correctly handle Avx10 nodes? Just to confirm.

[tannergooding]

Right. Avx10v1_v256 is just part of Avx10v1, so it's unnecessary.

Likewise, Avx10v1_v512 is really just Avx10v1 + Avx512, so doing those checks instead fits the need and saves us bits.

[Ruihan-Yin]

Thanks for the inputs,

There are duplicated implications there: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetDesc.txt#L141

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

Edit:
If we remove Avx10v1_V512, then the node definitions here might need some refactoring? It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

[tannergooding]

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

No and I'm actually fixing that in #103241

It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

Right, this is what I had meant should happen.

Any refactoring that changes how InstructionSet_* works might be possible but would be a more involved change.

[Ruihan-Yin]

Thanks for the explanation, in that case, I can wait for this PR go in first, and I will handle the conflict accordingly.

[jkotas]

You will also need to fix this to check that all feature bits are present for features described by multiple bits.

[jkotas]

Suggested change

	switch(instructionSet)
	{
	caseInstructionSet.X64_AVX10v1_V512:
	caseInstructionSet.X64_AVX10v1_V512_X64:
	caseInstructionSet.X64_AVX512F_VL:
	caseInstructionSet.X64_AVX512F_VL_X64:
	caseInstructionSet.X64_AVX512BW_VL:
	caseInstructionSet.X64_AVX512BW_VL_X64:
	caseInstructionSet.X64_AVX512CD_VL:
	caseInstructionSet.X64_AVX512CD_VL_X64:
	caseInstructionSet.X64_AVX512DQ_VL:
	caseInstructionSet.X64_AVX512DQ_VL_X64:
	caseInstructionSet.X64_AVX512VBMI_VL:
	caseInstructionSet.X64_AVX512VBMI_VL_X64:
	if(!uint.IsPow2((uint)flag))
	{

You should be able to just check whether the flag has one or more bits.

[jkotas]

Suggested change

	codeStream.Emit(ILOpcode.beq);
	codeStream.Emit(ILOpcode.ceq);

beq is "branch on equal". This is needs to be compare instead.

[Ruihan-Yin]

Corrected, thanks for pointing out!

[Ruihan-Yin]

rebased the branch to resolve conflicts.

I kept Avx10v1_V512 as an ISA to make it consistent with the node definition in hwintrinsicxarchlist.h. If we need further changes, I can try to make it within this PR.

The fails look like connection issue.

[Ruihan-Yin]

Hi @tannergooding,

Just making sure, I am looking at the #103241, in that PR, we have folded all the Avx512 bits into 1, is that expected moving on, or we are still looking for separate them out to be F+VL+BW+CD+DQ as discussed here. If not, I suppose the only thing left for this PR would be removing Avx10v1_V512?

Edit:
Conflicts have been resolved, I have only pushed the changes for Avx10v1 part first. For Avx512, I kept it to what has been changes in #103241, if we want to expand Avx512 flags, I will make the changes accordingly.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[Ruihan-Yin]

Except known failures, the build fail looks like due to timeout, and not related the changes.

[tannergooding]

Rerunning CI to get it in a clean state

[Ruihan-Yin]

Build Analysis has shown green, PR should be in clean state.

[tannergooding]

@jkotas, did you have any other feedback here or can I merge once CI is showing green?

[jkotas]

LGTM

[Ruihan-Yin]

I was not able to reproduce the CI fail locally.

From the call stack, it is more likely to be connection issue.

[Ruihan-Yin]

Thanks for all the suggestions and help!

[Ruihan-Yin]

More context in #103019 (comment)

To save some space in XArchIntrinsicConstants, this PR turns Avx512*_VL ISA flags per subset into a converged flag: Avx512F_VL, such that we can hold more ISAs within this enum, this will be the pre-work for the ongoing APX project.

[tannergooding]

Can we just have this be Avx512vl, as that's the actual CPUID feature name and matches the casing we use elsewhere?

[Ruihan-Yin]

I agree, will rename this part accordingly.

[tannergooding]

It'd be nice to remove these as well.

The former is unnecessary and the latter is implied by Avx512F existing.

[Ruihan-Yin]

I can make this change, and just make sure, does this part have conflicting changes with the ongoing Avx10 PR? I know some changes happening there for this as well, but didn't follow closely.

[tannergooding]

That PR is removing Avx10v1_v256, so removing it here as well should help avoid a conflict.

[Ruihan-Yin]

I saw Avx10v1_V256 was removed from InstructionSetDesc.txt, so what we want here is don't even define Avx10v1_V256 and Avx10v1_V512, and rely on EVEX to make sure JIT backend will correctly handle Avx10 nodes? Just to confirm.

[tannergooding]

Right. Avx10v1_v256 is just part of Avx10v1, so it's unnecessary.

Likewise, Avx10v1_v512 is really just Avx10v1 + Avx512, so doing those checks instead fits the need and saves us bits.

[Ruihan-Yin]

Thanks for the inputs,

There are duplicated implications there: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetDesc.txt#L141

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

Edit:
If we remove Avx10v1_V512, then the node definitions here might need some refactoring? It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

[tannergooding]

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

No and I'm actually fixing that in #103241

It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

Right, this is what I had meant should happen.

Any refactoring that changes how InstructionSet_* works might be possible but would be a more involved change.

[Ruihan-Yin]

Thanks for the explanation, in that case, I can wait for this PR go in first, and I will handle the conflict accordingly.

[jkotas]

You will also need to fix this to check that all feature bits are present for features described by multiple bits.

[jkotas]

Suggested change

	switch(instructionSet)
	{
	caseInstructionSet.X64_AVX10v1_V512:
	caseInstructionSet.X64_AVX10v1_V512_X64:
	caseInstructionSet.X64_AVX512F_VL:
	caseInstructionSet.X64_AVX512F_VL_X64:
	caseInstructionSet.X64_AVX512BW_VL:
	caseInstructionSet.X64_AVX512BW_VL_X64:
	caseInstructionSet.X64_AVX512CD_VL:
	caseInstructionSet.X64_AVX512CD_VL_X64:
	caseInstructionSet.X64_AVX512DQ_VL:
	caseInstructionSet.X64_AVX512DQ_VL_X64:
	caseInstructionSet.X64_AVX512VBMI_VL:
	caseInstructionSet.X64_AVX512VBMI_VL_X64:
	if(!uint.IsPow2((uint)flag))
	{

You should be able to just check whether the flag has one or more bits.

[jkotas]

Suggested change

	codeStream.Emit(ILOpcode.beq);
	codeStream.Emit(ILOpcode.ceq);

beq is "branch on equal". This is needs to be compare instead.

[Ruihan-Yin]

Corrected, thanks for pointing out!

[Ruihan-Yin]

rebased the branch to resolve conflicts.

I kept Avx10v1_V512 as an ISA to make it consistent with the node definition in hwintrinsicxarchlist.h. If we need further changes, I can try to make it within this PR.

The fails look like connection issue.

[Ruihan-Yin]

Hi @tannergooding,

Just making sure, I am looking at the #103241, in that PR, we have folded all the Avx512 bits into 1, is that expected moving on, or we are still looking for separate them out to be F+VL+BW+CD+DQ as discussed here. If not, I suppose the only thing left for this PR would be removing Avx10v1_V512?

Edit:
Conflicts have been resolved, I have only pushed the changes for Avx10v1 part first. For Avx512, I kept it to what has been changes in #103241, if we want to expand Avx512 flags, I will make the changes accordingly.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[Ruihan-Yin]

Except known failures, the build fail looks like due to timeout, and not related the changes.

[tannergooding]

Rerunning CI to get it in a clean state

[Ruihan-Yin]

Build Analysis has shown green, PR should be in clean state.

[tannergooding]

@jkotas, did you have any other feedback here or can I merge once CI is showing green?

[jkotas]

LGTM

[Ruihan-Yin]

I was not able to reproduce the CI fail locally.

From the call stack, it is more likely to be connection issue.

[Ruihan-Yin]

Thanks for all the suggestions and help!

[Ruihan-Yin]

More context in #103019 (comment)

To save some space in XArchIntrinsicConstants, this PR turns Avx512*_VL ISA flags per subset into a converged flag: Avx512F_VL, such that we can hold more ISAs within this enum, this will be the pre-work for the ongoing APX project.

[tannergooding]

Can we just have this be Avx512vl, as that's the actual CPUID feature name and matches the casing we use elsewhere?

[Ruihan-Yin]

I agree, will rename this part accordingly.

[tannergooding]

It'd be nice to remove these as well.

The former is unnecessary and the latter is implied by Avx512F existing.

[Ruihan-Yin]

I can make this change, and just make sure, does this part have conflicting changes with the ongoing Avx10 PR? I know some changes happening there for this as well, but didn't follow closely.

[tannergooding]

That PR is removing Avx10v1_v256, so removing it here as well should help avoid a conflict.

[Ruihan-Yin]

I saw Avx10v1_V256 was removed from InstructionSetDesc.txt, so what we want here is don't even define Avx10v1_V256 and Avx10v1_V512, and rely on EVEX to make sure JIT backend will correctly handle Avx10 nodes? Just to confirm.

[tannergooding]

Right. Avx10v1_v256 is just part of Avx10v1, so it's unnecessary.

Likewise, Avx10v1_v512 is really just Avx10v1 + Avx512, so doing those checks instead fits the need and saves us bits.

[Ruihan-Yin]

Thanks for the inputs,

There are duplicated implications there: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetDesc.txt#L141

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

Edit:
If we remove Avx10v1_V512, then the node definitions here might need some refactoring? It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

[tannergooding]

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

No and I'm actually fixing that in #103241

It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

Right, this is what I had meant should happen.

Any refactoring that changes how InstructionSet_* works might be possible but would be a more involved change.

[Ruihan-Yin]

Thanks for the explanation, in that case, I can wait for this PR go in first, and I will handle the conflict accordingly.

[jkotas]

You will also need to fix this to check that all feature bits are present for features described by multiple bits.

[jkotas]

Suggested change

	switch(instructionSet)
	{
	caseInstructionSet.X64_AVX10v1_V512:
	caseInstructionSet.X64_AVX10v1_V512_X64:
	caseInstructionSet.X64_AVX512F_VL:
	caseInstructionSet.X64_AVX512F_VL_X64:
	caseInstructionSet.X64_AVX512BW_VL:
	caseInstructionSet.X64_AVX512BW_VL_X64:
	caseInstructionSet.X64_AVX512CD_VL:
	caseInstructionSet.X64_AVX512CD_VL_X64:
	caseInstructionSet.X64_AVX512DQ_VL:
	caseInstructionSet.X64_AVX512DQ_VL_X64:
	caseInstructionSet.X64_AVX512VBMI_VL:
	caseInstructionSet.X64_AVX512VBMI_VL_X64:
	if(!uint.IsPow2((uint)flag))
	{

You should be able to just check whether the flag has one or more bits.

[jkotas]

Suggested change

	codeStream.Emit(ILOpcode.beq);
	codeStream.Emit(ILOpcode.ceq);

beq is "branch on equal". This is needs to be compare instead.

[Ruihan-Yin]

Corrected, thanks for pointing out!

[Ruihan-Yin]

rebased the branch to resolve conflicts.

I kept Avx10v1_V512 as an ISA to make it consistent with the node definition in hwintrinsicxarchlist.h. If we need further changes, I can try to make it within this PR.

The fails look like connection issue.

[Ruihan-Yin]

Hi @tannergooding,

Just making sure, I am looking at the #103241, in that PR, we have folded all the Avx512 bits into 1, is that expected moving on, or we are still looking for separate them out to be F+VL+BW+CD+DQ as discussed here. If not, I suppose the only thing left for this PR would be removing Avx10v1_V512?

Edit:
Conflicts have been resolved, I have only pushed the changes for Avx10v1 part first. For Avx512, I kept it to what has been changes in #103241, if we want to expand Avx512 flags, I will make the changes accordingly.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[Ruihan-Yin]

Except known failures, the build fail looks like due to timeout, and not related the changes.

[tannergooding]

Rerunning CI to get it in a clean state

[Ruihan-Yin]

Build Analysis has shown green, PR should be in clean state.

[tannergooding]

@jkotas, did you have any other feedback here or can I merge once CI is showing green?

[jkotas]

LGTM

[Ruihan-Yin]

I was not able to reproduce the CI fail locally.

From the call stack, it is more likely to be connection issue.

[Ruihan-Yin]

Thanks for all the suggestions and help!

[Ruihan-Yin]

More context in #103019 (comment)

To save some space in XArchIntrinsicConstants, this PR turns Avx512*_VL ISA flags per subset into a converged flag: Avx512F_VL, such that we can hold more ISAs within this enum, this will be the pre-work for the ongoing APX project.

[tannergooding]

Can we just have this be Avx512vl, as that's the actual CPUID feature name and matches the casing we use elsewhere?

[Ruihan-Yin]

I agree, will rename this part accordingly.

[tannergooding]

It'd be nice to remove these as well.

The former is unnecessary and the latter is implied by Avx512F existing.

[Ruihan-Yin]

I can make this change, and just make sure, does this part have conflicting changes with the ongoing Avx10 PR? I know some changes happening there for this as well, but didn't follow closely.

[tannergooding]

That PR is removing Avx10v1_v256, so removing it here as well should help avoid a conflict.

[Ruihan-Yin]

I saw Avx10v1_V256 was removed from InstructionSetDesc.txt, so what we want here is don't even define Avx10v1_V256 and Avx10v1_V512, and rely on EVEX to make sure JIT backend will correctly handle Avx10 nodes? Just to confirm.

[tannergooding]

Right. Avx10v1_v256 is just part of Avx10v1, so it's unnecessary.

Likewise, Avx10v1_v512 is really just Avx10v1 + Avx512, so doing those checks instead fits the need and saves us bits.

[Ruihan-Yin]

Thanks for the inputs,

There are duplicated implications there: https://github.com/dotnet/runtime/blob/main/src/coreclr/tools/Common/JitInterface/ThunkGenerator/InstructionSetDesc.txt#L141

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

Edit:
If we remove Avx10v1_V512, then the node definitions here might need some refactoring? It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

[tannergooding]

Are they intended to be like this, or this shall be removed, I can make the changes if needed.

No and I'm actually fixing that in #103241

It looks fine to just remove it from XArchIntrinsicConstants but keep the definition as an ISA, and as mentioned, set InstructionSet_Avx10v1_V512 based on XArchIntrinsicConstants_Avx10v1 and XArchIntrinsicConstants_Avx512f

Right, this is what I had meant should happen.

Any refactoring that changes how InstructionSet_* works might be possible but would be a more involved change.

[Ruihan-Yin]

Thanks for the explanation, in that case, I can wait for this PR go in first, and I will handle the conflict accordingly.

[jkotas]

You will also need to fix this to check that all feature bits are present for features described by multiple bits.

[jkotas]

Suggested change

	switch(instructionSet)
	{
	caseInstructionSet.X64_AVX10v1_V512:
	caseInstructionSet.X64_AVX10v1_V512_X64:
	caseInstructionSet.X64_AVX512F_VL:
	caseInstructionSet.X64_AVX512F_VL_X64:
	caseInstructionSet.X64_AVX512BW_VL:
	caseInstructionSet.X64_AVX512BW_VL_X64:
	caseInstructionSet.X64_AVX512CD_VL:
	caseInstructionSet.X64_AVX512CD_VL_X64:
	caseInstructionSet.X64_AVX512DQ_VL:
	caseInstructionSet.X64_AVX512DQ_VL_X64:
	caseInstructionSet.X64_AVX512VBMI_VL:
	caseInstructionSet.X64_AVX512VBMI_VL_X64:
	if(!uint.IsPow2((uint)flag))
	{

You should be able to just check whether the flag has one or more bits.

[jkotas]

Suggested change

	codeStream.Emit(ILOpcode.beq);
	codeStream.Emit(ILOpcode.ceq);

beq is "branch on equal". This is needs to be compare instead.

[Ruihan-Yin]

Corrected, thanks for pointing out!

[Ruihan-Yin]

rebased the branch to resolve conflicts.

I kept Avx10v1_V512 as an ISA to make it consistent with the node definition in hwintrinsicxarchlist.h. If we need further changes, I can try to make it within this PR.

The fails look like connection issue.

[Ruihan-Yin]

Hi @tannergooding,

Just making sure, I am looking at the #103241, in that PR, we have folded all the Avx512 bits into 1, is that expected moving on, or we are still looking for separate them out to be F+VL+BW+CD+DQ as discussed here. If not, I suppose the only thing left for this PR would be removing Avx10v1_V512?

Edit:
Conflicts have been resolved, I have only pushed the changes for Avx10v1 part first. For Avx512, I kept it to what has been changes in #103241, if we want to expand Avx512 flags, I will make the changes accordingly.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

[Ruihan-Yin]

Except known failures, the build fail looks like due to timeout, and not related the changes.

[tannergooding]

Rerunning CI to get it in a clean state

[Ruihan-Yin]

Build Analysis has shown green, PR should be in clean state.

[tannergooding]

@jkotas, did you have any other feedback here or can I merge once CI is showing green?

[jkotas]

LGTM

[Ruihan-Yin]

I was not able to reproduce the CI fail locally.

From the call stack, it is more likely to be connection issue.

[Ruihan-Yin]

Thanks for all the suggestions and help!