This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: HWCAP is method to determine cpu features, not selection mechanism.
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 10 Jun 2015 15:16:57 +0100
- Subject: Re: HWCAP is method to determine cpu features, not selection mechanism.
- Authentication-results: sourceware.org; auth=none
- References: <55760314 dot 6070601 at linux dot vnet dot ibm dot com> <5576FC80 dot 1090806 at arm dot com> <1433862393 dot 21101 dot 9 dot camel at sjmunroe-ThinkPad-W500> <20150609154223 dot GA20028 at domone> <1433865684 dot 21101 dot 20 dot camel at sjmunroe-ThinkPad-W500> <20150610125047 dot GA10861 at domone> <55783D2A dot 8050703 at linaro dot org>
On 10/06/15 14:35, Adhemerval Zanella wrote:
> I agree that adding an API to modify the current hwcap is not a good
> approach. However the cost you are assuming here are *very* x86 biased,
> where you have only on instruction (movl <variable>(%rip), %<destiny>)
> to load an external variable defined in a shared library, where for
> powerpc it is more costly:
debian codesearch found 4 references to __builtin_cpu_supports
all seem to avoid using it repeatedly.
multiversioning dispatch only happens at startup (for a small
number of functions according to existing practice).
so why is hwcap expected to be used in hot loops?