[PATCH v2] x86: Add support for AVX10 version and vec size in cpu-features
Florian Weimer
fweimer@redhat.com
Fri Aug 25 07:12:15 GMT 2023
* Noah Goldstein via Libc-alpha:
> +/* AVX10 version information is handled differently from all other CPUID
> + related logic. Rather than being encoded in cpuid as discrete booleans, the
> + AVX10 version is encoded is a full byte that represents the version number
> + (greater than or equal to 1). Since the CPUID API is only able to handle
> + boolean returns, we enumerate `x86_cpu_AVX10_V{1..255}` which can be queried
> + by the user and have special logic in `x86_cpu_{present,active}`. This is
> + unpleasant on our end, but is the only way to make the existing API also
> + support version queries. */
> +
> + /* All 1s should never be a value feature index. */
> + x86_cpu_AVX10_V255 = ~0,
> + x86_cpu_AVX10_V254 = x86_cpu_AVX10_V255 - 1,
> + x86_cpu_AVX10_V253 = x86_cpu_AVX10_V254 - 1,
> + x86_cpu_AVX10_V252 = x86_cpu_AVX10_V253 - 1,
> + x86_cpu_AVX10_V251 = x86_cpu_AVX10_V252 - 1,
Is this really necessary? We can define an x86_cpu_avx10_version inline
function that calls __x86_get_cpuid_feature_leaf and extracts the
version byte. Is it really necessary to support something like this?
CPU_FEATURE_ACTIVE (AVX10_V2)
This would be the alternative:
x86_cpu_avx10_version () >= 2
Let's hope that version 0 means no AVX10. 8-)
Thanks,
Florian
More information about the Libc-alpha
mailing list