GFNI documentation anomaly

[Beulich__Jan]

The ISA extensions document has been listing all variants as dependent upon the GFNI feature flag plus, for the AVX variants, respective further feature flags. In the second to most recent SDM version the legacy encodings have got added, but the VEX/EVEX ones haven't been. This did not change in the most recent version. But the current state of things leaves ambiguous whether VEX/EVEX encoded variants are qualified by the base GFNI feature flag (plus the necessary AVX* ones), or whether there's going to be a VGFNI feature flag (along the lines of VPCLMULQDQ and VAES) when the other encodings also get moved to the SDM. That's because with how the SDM is written right now, the combination of e.g. AVX+GFNI does not render the VEX-encoded forms legitimate, i.e. expected behavior would be for these to #UD.

As an aside, note how the GF2P8MULB SDM page mentions VGF2P8MULB in the compiler intrinsics section, but the two GF2P8AFFINE* pages don't.

[MarkC_Intel]

Hi Jan, please look at the individual instructions to see how they are enumerated via CPUID.  Briefly,  SSE GFNI is identified with the GFNI bit.  AVX versions of GFNI are indentified by the conjunction of GFNI and AVX cpuid bits.  AVX512 with VL=128 or 256 are identified by the conjunction of AVX512VL and GFNI. And the AVX512 VL=512 version by the conjunction of AVX512F and GFNI.  Technically the AVX512 versions with VL=128 & 256 include AVX512F but that is redundant with AVX512VL (as AVX512VL implies AVX512F).     We used different enumeration schemes with other instruction extensions because of the evolutionary order in which they were introduced - we could not use logical conjunction in all cases.

[Beulich__Jan]

Thanks Mark. The enumeration model is clear though - the question was on the odd split of information between SDM and ISA extensions doc. One would generally expect that coding to the SDM alone would produce consistent code. Yet that's not going to be the case with only the legacy encodings listed in the SDM right now.

[MarkC_Intel]

Hi Jan, thanks for the clarification of your question. The general rule we try to use is that SDM is for stuff that is available in products (or close to availability) or for stuff that would be too hard to put in a separate document because of a large intersection with existing documentation.  The ISE doc is for stuff that has not yet reached that stage. That is why the GFNI instructions are spread across the two documents.  The SSE-versions of the GFNI are in the Tremont microarchitecture. Icelake adds more (and includes the SSE versions as well).  The rules are not set in stone and kind of evolved out of how we introduced the AVX instructions. 

[Beulich__Jan]

Oh, I see - it didn't even occur to me that there could be new processors without AVX. But I see SDE emulates it exactly as you imply - with GFNI, but without AVX.