This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCHv5] - powerpc: Add hwcap/hwcap2/platform data to TCB.


On Mon, 2015-10-26 at 15:07 -0500, Steven Munroe wrote:
> On Mon, 2015-10-26 at 12:35 -0500, Peter Bergner wrote:
>> used below.  You only need to cast them just before you merge
>> them into __tcb_hwcap.
>
> because later we need to shift left 32-bits, which drop information
> if we declared them 32-bit.

I did say we had to cast them to 64-bit just before we merge them
into __tcb_hwcap. :-)  That meant doing the shift and or using 64-bit
operations.



>>   __tcb_hwcap = ((uint64_t)h1 << 32) | (uint64_t) h2;
>
> Are you sure current an future versions of GCC will handle this
> promotion to 64-bit correctly across the shift and or operation?

Of course.  If that doesn't work, we've got big problems. :-)



> You can not have both. You either have single 64-bit load for BE and
> LE, or you can have fixed (same for BE/LE) offset for the separate
> HWCAP/HWCAP2.

On the glibc side, you can have fixed offsets for HWCAP and HWCAP2 and
do one store to initialize the TCB.  It just takes a little marshalling
of the two values in the register before we store them.  On the gcc side
(ie, loading of the TCB value(s))...


> The alternative requires spectate mask generation for BE/LE around
> any single 64-bit load (think about any if where you need to test
> one bit each in HWCAP and HWCAP2).

I don't think we'll have many cases where we do:

  __builtin_cpu_supports ("XXX") <logical_op> __builtin_cpu_supports ("YYY")

For the PPC_FEATURE_ARCH_* flags, glibc has already set the PPC_FEATURE_*
flags that are implied by the actual PPC_FEATURE_ARCH* flag, so theres no
need to check for say "PPC_FEATURE_ARCH_2_06" || "PPC_FEATURE_ARCH_2_05",
since we only have to check for the lowest common denominator ISA value.
For the other flags, I find it hard to think of why we'd test for things
like "dfp" && "htm", or even "vsx" || "altivec", since the later is the
same as checking for "altivec" alone.  

Is there a usage case I'm not thinking of?  If not, I had planned on just
doing a lwz of the appropriate HWCAP{,2} value and comparing.  The nice
thing about that, is that the gcc code is the same for 32-bit versus
64-bit and ditto for LE versus BE.

I'll note that __builtin_cpu_supports (...) as defined doesn't support
passing in multiple feature strings.

Peter



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]