This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V4 [PATCH] 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: "H.J. Lu" <hongjiu dot lu at intel dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 20 Sep 2018 05:39:16 -0700
- Subject: Re: V4 [PATCH] x86: Add <sys/platform/x86.h>
- References: <20180919131313.GA7503@intel.com> <87o9csflaf.fsf@oldenburg.str.redhat.com>
On Thu, Sep 20, 2018 at 4:41 AM, Florian Weimer <fweimer@redhat.com> wrote:
> * H. J. Lu:
>
>> Add <sys/platform/x86.h> to provide an API to access x86 specific platform
>> features. It makes raw and derived CPUID information available to
>> applications so that programmers can avoid complicated steps to retrieve
>> the same information with CPUID instructions.
>
> Sorry, I still think that this patch semantically depends on delayed
> IFUNC processing.
>
> Furthermore, I strongly prefer a simplified interface, like:
>
> enum {
> X86_FEATURE_MMX,
> X86_FEATURE_SSE,
> X86_FEATURE_SSE2,
> …
> X86_FEATURE_AVX512F,
> …
> };
>
> _Bool x86_feature_usable (int index) __attribute__ ((pure));
>
> Applications could then do something like this:
>
> if (x86_feature_usable (X86_FEATURE_AVX512F))
> return &__matmul_avx512f;
>
> I don't think there is value in exposing the CPUID data directly. If
> programmers need it, they can use <cpuid.h> from GCC instead, without
> needing to worry how glibc populates its data structures.
>
You have 2 concerns. Which one is the primary concern? Or
are both blockers for you?
--
H.J.