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

[Florian Weimer <fweimer at redhat dot com>]

* H. J. Lu:

> 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.

I think this interface should be targeted at discovering features, not
CPU models, to avoid confusion.

If you need to figure out the model, you really need to look at CPUID
results.  Everything else will be brittle, due to evolving CPU lines and
virtualization.

Thanks,
Florian