This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: V5 [PATCH 1/2] x86: Add <sys/platform/x86.h>


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]