[PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
Adhemerval Zanella
adhemerval.zanella@linaro.org
Tue Jun 9 18:18:00 GMT 2015
On 09-06-2015 13:38, Rich Felker wrote:
> On Mon, Jun 08, 2015 at 06:03:16PM -0300, Carlos Eduardo Seo wrote:
>>
>> The proposed patch adds a new feature for powerpc. In order to get
>> faster access to the HWCAP/HWCAP2 bits, we now store them in the
>> TCB. This enables users to write versioned code based on the HWCAP
>> bits without going through the overhead of reading them from the
>> auxiliary vector.
>>
>> A new API is published in ppc.h for get/set the bits in the
>> aforementioned memory area (mainly for gcc to use to create
>> builtins).
>
> Do you have any justification (actual performance figures for a
> real-world usage case) for adding ABI constraints like this? This is
> not something that should be done lightly. My understanding is that
> hwcap bits are normally used in initializing functions pointers (or
> equivalent things like ifunc resolvers), not again and again at
> runtime, so I'm having a hard time seeing how this could help even if
> it does make the individual hwcap accesses measurably faster.
I believe the idea is to provide a fast way to emulate a functionality
similar to __builtin_cpu_supports for powerpc. For x86, this builtin
will create 'cpuid' instruction, but since powerpc lacks a similar one
it should rely on hardware capability information provided by kernel.
And using TCB is the fastest way to provide such functionality. By
exporting the symbol as a normal variable (extern int hwcap), it will
require a R_PPC64_ADDR64 relocation plus two load accesses and some
arithmetic (TOC materialization and load plus the variable load)
>
> It would also be nice to see some justification for the magic number
> offsets. Will they be stable under changes to the TCB structure or
> will preserving them require tip-toeing around them?
It requires not change TCB fields over releases and adding newer on top
(to not change previous offset). And it has been done for a while,
since the ssp canary.
>
> Rich
>
More information about the Libc-alpha
mailing list