[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