Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

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
>