This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V5 [PATCH 1/2] x86: Add <sys/platform/x86.h>
- From: Florian Weimer <fweimer at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 24 Oct 2018 11:40:51 +0200
- Subject: Re: V5 [PATCH 1/2] x86: Add <sys/platform/x86.h>
- References: <20180927194327.7683-1-hjl.tools@gmail.com> <20180927194327.7683-2-hjl.tools@gmail.com> <874ldb9036.fsf@oldenburg.str.redhat.com> <CAMe9rOo4iF7GdLe39Y4W6BZN78BCsk4UErCtL3ee1e4=_cbYww@mail.gmail.com>
* 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.
Thanks,
Florian