V5 [PATCH 1/2] x86: Add <sys/platform/x86.h>
H.J. Lu
hjl.tools@gmail.com
Wed Oct 24 10:34:00 GMT 2018
On 10/24/18, Florian Weimer <fweimer@redhat.com> wrote:
> * H. J. Lu:
>
>> On 10/24/18, Florian Weimer <fweimer@redhat.com> wrote:
>>> * H. J. Lu:
>>>
>>>> +@defmac HAS_CPU_FEATURE(name)
>>>> +
>>>> +Evaluate to true if the CPU feature @code{name} is supported as
>>>> indicated
>>>> +by @code{CPUID} instruction. The available features are:
>>>
>>> I'm still puzzled why we expose this function. It will only confuse
>>> programmers.
>>
>> A use case: AVX512 bits can be used to tell Xeon Phi from Skylake
>> sever even if AVX512 instructions aren't used/needed at all.
>
> Do you mean checking fore AVX512ER? Would you consider this good
> practice?
>
> It is actually future-proof? What if Skylake successors implement
> AVX512ER? Do you really want applications to select the Xeon Phi
> workarounds in this case?
>
> I still think if you care about Xeon Phi, you should use <cpuid.h> from
> GCC and make the checks as explicit as possible. The <cpuid.h>
> facilities should not be too difficult to use for that purpose.
Xeon Phi is an example. There are other cases where one may want to
know if a feature exists in CPU, not necessarily wants/needs to use the
feature. The main purpose of <sys/platform/x86.h> is to make it easier
to check if a feature is usable or exists.
--
H.J.
More information about the Libc-alpha
mailing list