This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv5] - powerpc: Add hwcap/hwcap2/platform data to TCB.
- From: Peter Bergner <bergner at vnet dot ibm dot com>
- To: munroesj at linux dot vnet dot ibm dot com
- Cc: Carlos Eduardo Seo <cseo at linux dot vnet dot ibm dot com>, GNU C Library <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>, Tulio Machado <tuliom at linux dot vnet dot ibm dot com>, "Steven J. Munroe" <sjmunroe at us dot ibm dot com>
- Date: Tue, 27 Oct 2015 17:50:14 -0500
- Subject: Re: [PATCHv5] - powerpc: Add hwcap/hwcap2/platform data to TCB.
- Authentication-results: sourceware.org; auth=none
- References: <462274D6-C7A4-4186-8B73-65BE70336DE6 at linux dot vnet dot ibm dot com> <1445880936 dot 30998 dot 34 dot camel at vnet dot ibm dot com> <1445890065 dot 11373 dot 18 dot camel at oc7878010663>
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