Any reason we're not adding the APIs at the same time? They look like they should be generally table driven, so it should be a minimal change on top...

We can do that too. For all other ISAs, we generally did CPUID and API introduction as separate PRs. Also, it becomes easier to run superpmi once the CPUID PR goes in. Let me know what you'd prefer.

For all other ISAs, we generally did CPUID and API introduction as separate PRs.

For some of the others, like AVX10.2, we've done it incrementally because of the number of APIs and total work required.

That is, checking in the CPUID support first allowed a reduction of conflicts and parallelization of adding a large number of intrinsic APIs across several PRs.

In this case, there's only a very small number of APIs that are likely entirely table driven, so there's little to no risk of conflicts or additional churn.

Doing it all at once lets us build confidence the CPUID checks and end to end story is correct since it is self contained like that and since it allows adding the CPUID and other tests at the same time.

Also, it becomes easier to run superpmi once the CPUID PR goes in

There's not much need to run SPMI for net new intrinsics that nothing is using yet, we're going to get zero diffs.

Ohkay. Thanks for the review. I will switch this PR to add everything together and then update you.

avxvnniint8 and avxvnniint16 should be added with the other VEX instruction sets, where avxvnni is. (you'll have conflicts with #114575 depending which lands first)

Ohkay. I was thinking that we add AvxVnniInt* in both the places. does that make sense? we want AvxVnniInt* to be available independently as well as with Avx10.2.

They only need to be added under the AVX check. AVX10v2 implies AVX, so both blocks will execute in that case.

n.b. the _V512 ones would stay where they are.

You'll need to add NAOT smoke tests for AVX10v2 as well, under https://github.com/dotnet/runtime/tree/main/src/tests/nativeaot/SmokeTests/HardwareIntrinsics

They should check that with Avx2 (today, or Avx after #114575) enabled, AvxVnniInt8+16 are optimistically supported (return null) and that with Avx10v2 enabled, they are enabled too (return true).
 
I'm not sure why AVX10v1 doesn't have a config too already, actually.

You'll need to add NAOT smoke tests for AVX10v2 as well, under https://github.com/dotnet/runtime/tree/main/src/tests/nativeaot/SmokeTests/HardwareIntrinsics

They should check that with Avx2 (today, or Avx after #114575) enabled, AvxVnniInt8+16 are optimistically supported (return null) and that with Avx10v2 enabled, they are enabled too (return true).   I'm not sure why AVX10v1 doesn't have a config too already, actually.

Looking into this.

The spec I have doesn't list VEX encodings for the instructions -- only EVEX.

What I'm saying is that while the instructions are supported, I'm not sure it's safe to assume the VEX encodings of them will be supported unless we explicitly check the AVX-VNNI-INT8/16 flag as well.

True. We cannot say that Vex encodings of AvxVnniInt* will be supported if Evex encodings will be supported. But where do you want to put the ISA checks? If Avx10.2 is not available and AvxVnniInt* is, that should be suffice to asusme Vex encoding support according to me.

If Avx10.2 is not available and AvxVnniInt* is, that should be suffice to asusme Vex encoding support

That's correct. You can assume that no AVX10.2 means the support must come from AVX-VNNI-INT* and that VEX is supported.

However, Avx10.2 currently implies AvxVnniInt*, which means you have no way to check that the instructions are supported but that VEX encoding is not. If AVX10.2 only guarantees EVEX encoding support, you need an additional ISA you can check for VEX support, which is why I suggested a third ISA for each of these.

where do you want to put the ISA checks?

I believe you'll want to look at emitter::TakesEvexPrefix, where typically we will only choose EVEX encoding when necessary (for kmask, embedded broadcast, or extended registers). There needs to be an additional check for these new instructions that says that when the VEX support ISA is not present, they must be EVEX.

Again, this is only if the spec has not been revised since the last publication to indicate that the VEX form is guaranteed to be valid.

I think we have a conclusion here.
Avx10.2 will support Evex as well as Vex versions of Avx-Vnni-Int* instructions. This would mostly clear up all our discussions since now, we can move forward assuming that we will either have support for Vex or both Vex adn Evex versions of these instructions. The change should reflect in my latest commit.

@saucecontrol for review.

When AVX-VNNI-INT8/16 CPUID bits are set, these instructions support VEX encoding. Only if AVX10.2 is also supported would they support EVEX-encoded forms.

There are definitely CPUs in the wild that support the VEX forms only (e.g. Lunar Lake). I think the current modeling of the ISAs will only work if it's guaranteed that anything supporting the EVEX form also supports VEX. In other words, we'd have to say that AVX10.2 implies AVX-VNNI-INT8/16, which the spec doesn't support.

We have the same issue modeling AVX-VNNI, where AVX10.1 says the instructions are available but only guarantees the EVEX forms.

We solved a similar problem with PCLMULQDQ and VPCLMULQDQ, where additional ISA checks are required in order to know whether VEX and EVEX encoding are supported. However, in that case we knew that VPCLMULQDQ strictly implied PCLMULQDQ, and EVEX encoding required AVX-512VL+VPCLMULQDQ, which we could check separately. In other words, you could have VEX-only, but you couldn't have EVEX without VEX.

Added a patch in my latest commit to see if handling vex encodings can help with the test failures.

This too shall be resolved with #113956 (comment)

This doesn't look correct. We shouldn't be selecting some NI_EVEX_* intrinsic for the VEX encoding.

We should instead select NI_AVXVNNIINT8_MultiplyWideningAndAdd and then that can implicitly upgrade to the EVEX form, much as NI_SSE_Add can do.

Yes. I have changed the implementation to reflect this and we will use Vex encoding where only Avx-Vnni-Int* is present.

nit: This should probably be using the JITDUMP or alternative API rather than just calling printf

I was not able to reproduce it offline so was trying to debug from CI. I have removed it now.

We shouldn't need any of these EVEX cases. The NI_EVEX_* intrinsics are largely for special intrinsics that deal with masks and which do not map directly to a managed signature.

Yes. I was using them as a fallback for all the Avx-Vnni-Int* APIs since the APIs had same names with same type of first 2 args. But that is resolved now with my latest change.

Hi @saucecontrol
Looks like we cannot add the smoketest for Avx10 just yet. We can do it once IsProcessorFeaturePresent (link) supports Avx10. Do you agree? Until then, the smoketest will keep failing.