Consider renaming the `avx512gfni` feature to just `gfni`

[calebzulawski]

While GFNI has (optional) AVX-512 instructions, there is at least one microarchitecture (Tremont) that has GFNI without AVX-512.

This is further confirmed by running:

rustc +nightly -Ctarget-feature=+avx512gfni --print cfg | grep target_feature
target_feature="avx512gfni"
target_feature="cmpxchg16b"
target_feature="fxsr"
target_feature="llvm14-builtins-abi"
target_feature="sse"
target_feature="sse2"
target_feature="sse3"
target_feature="ssse3"

Unlike other AVX-512 features, avx512f is not enabled, so I'm not sure this should be considered an AVX-512 feature.

[calebzulawski]

The same goes for avx512vaes to vaes, which seems to be implemented on Zen 3 without AVX-512.

[workingjubilee]

This.. seems incorrect. The versions that don't build off and include AVX512 should be separate features, if I remember the ad copy around these.

[calebzulawski]

I'm not sure if you mean my suggestion is incorrect, or the existing feature names, but rustc certainly isn't the first to be confused by the new convention used here: https://community.intel.com/t5/Intel-ISA-Extensions/GFNI-documentation-anomaly/td-p/1153193

[workingjubilee]

I am mostly expressing bafflement at the current situation.

[SchrodingerZhu]

Please also see rust-lang/stdarch#1343

On AMD platform, VAES (I doubt VPCLMULQDQ) codegen would suffer from the similar issue mentioned here.