Re: [PATCH v2 3/3] powerpc64le: Add glibc-hwcaps support

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Tulio Magno Quites Machado Filho:

> Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:
>
>> The "power10" and "power9" subdirectories are selected.
>
> Tested on power10.
>
> Should this patch also include modification to
> glibc-hwcaps-first-subdirs-for-tests ?

Yes, it should.  In the posted version, it depended on power9 being
included in the first patch tht added the generic test.

> Is it intentional that other architectures end up with the following file?
>
>     elf/glibc-hwcaps/x86-64-v2/markermod1.so

Yes, it doesn't hurt, and it allows us to keep the test generic.

>> diff --git a/sysdeps/powerpc/powerpc64/le/dl-hwcaps-subdirs.c b/sysdeps/powerpc/powerpc64/le/dl-hwcaps-subdirs.c
>> new file mode 100644
>> index 0000000000..1fa3735a8c
>> --- /dev/null
>> +++ b/sysdeps/powerpc/powerpc64/le/dl-hwcaps-subdirs.c
>> @@ -0,0 +1,39 @@
>>...
>> +
>> +uint32_t
>> +_dl_hwcaps_subdirs_active (void)
>> +{
>> +  int active = 0;
>> +
>> +  if ((GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_00) == 0)
>> +    return _dl_hwcaps_subdirs_build_bitmask (subdirs_count, active);
>> +  ++active;
>> +
>> +  if ((GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_1) == 0)
>> +    return _dl_hwcaps_subdirs_build_bitmask (subdirs_count, active);
>
> This is the tricky part.  I like your proposal to match with the behavior
> of -mcpu.
> In that case we would have:
>
>   power9:
>     ((GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_00) == 0
>      || (GLRO (dl_hwcap2) & PPC_FEATURE2_HAS_IEEE128) == 0
>      || (GLRO (dl_hwcap) & PPC_FEATURE_HAS_ALTIVEC) == 0
>      || (GLRO (dl_hwcap) & PPC_FEATURE_HAS_VSX) == 0)
>
>   power10:
>     /* power10 also requires altivec, vsx and ieee128 availability, but these
>        features have already been tested.  */
>     ((GLRO (dl_hwcap2) & (PPC_FEATURE2_ARCH_3_1 | PPC_FEATURE2_MMA)) == 0)
>
> This would mean that a processor that implements POWER ISA 3.0, but does not
> implement altivec, would not be able to benefit from that particular library
> build, falling back to the general build (power8), e.g. microwatt would fall
> in this category right now.

I think we need documentation what it means for a processor to implement
ISA 3.0, and not altivec.  Or for that matter, what an implementation of
powerpc64le-*-linux-gnu without altivec looks like.  Presumably, it will
be different yet again from the original hardware used during
architecture bring-up.

Once we have no-altivec support for powerpc64le in the GNU toolchain, we
probably should add a power8 subdirectory that stores libraries that use
altivec/vsx.  (This directory would be searched even on systems which
are built to use altivec because they use the POWER8 baseline.)

>>   * The names "power9" and "power10" may be too implementation-specific in
>>     the future.
>
> I do agree, but I don't have a better suggestion.
> It's hard to be future-proof here.
> I don't think that using the POWER ISA level would help much though,
> because new processors may decide to not implement a particular feature
> in the future that we believe is essential right now.

One way to address this is to restrict the selected ISA features for
each level to something that has the most benefit and is unlikely to go
away.

ISA features that cannot automatically and pervasively used by compilers
can be excluded as well.  MMA could be in that category, and I think
cryptography-related instructions generally are.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill