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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 24 Oct 2018 03:12:07 -0700
- 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> <87r2gf7kd8.fsf@oldenburg.str.redhat.com>
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.