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

[Tulio Magno Quites Machado Filho via Libc-alpha <libc-alpha@sourceware.org>]

Florian Weimer <fweimer@redhat.com> writes:

> 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.

I think we already have this documented in a couple of places in different
documents from the OpenPOWER Foundation.

Up to POWER ISA 2.07 (included) [1], there existed categories of features that
processors may not implement.  Category Vector (aka. altivec) and category
Vector-Scalar Extension (aka. vsx) exist there and are listed in the
OpenPOWER Instruction Set Architecture Profile specification v1.1.0 [2] as
required in the OpenPOWER chip architecture.

POWER ISA 3.0 [3] dropped support for categories, but the OpenPOWER ISA
Compliance Definition 2.0 [4] lists specific sections of the POWER ISA document
that are required, with references to the Vector and Vector-Scalar chapters.

POWER ISA 3.1 [5] added the concept of OpenISA compliancy subset (page vi).
In this new concept, both Vector and Vector-Scalar are required for Linux
compliancy (aka. SIMD in ISA 3.1).

Furthermore, the POWER 64-bit ELF V2 ABI 1.5 [6], which is under public review,
states that:

    It expects an OpenPOWER-compliant processor to implement at least Power ISA
    V2.07B with all OpenPOWER Architecture instruction categories as well as
    OpenPOWER-defined implementation characteristics for some
    implementation-specific features.

It's also worth mentioning that it's removing the list of categories that was
duplicated from [2] which used to mention Vector and Vector-Scalar.

With all that said, it's clear to notice these requirements add barriers for
new processors to start booting Linux. In order to minimize that, I've been
working on some ifunc functions in glibc so that they do not make assumptions
based on IBM processors and are either adapted to work on new processors or
are correctly ignored.

[1] https://openpowerfoundation.org/?resource_lib=ibm-power-isa-version-2-07-b
[2] http://cdn.openpowerfoundation.org/wp-content/uploads/resources/isa-profile/content/ch_profile.html
[3] https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0
[4] http://cdn.openpowerfoundation.org/wp-content/uploads/resources/openpower-isa-thts-V2-1/content/_Ref436814652.html
[5] https://ibm.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0
[6] https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-review-draft

> 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.)

Per my previous explanation, I don't think this is necessary for
OpenPOWER-compliant systems.

>>>   * 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.

As I've just reviewed the OpenPOWER ISA Compliance documents [2] [4], they do
make the usage of the terms "power8" and "power9".  So, I feel better in using
them.  Notice that a definition for power10 is not available yet, except
for the OpenISA compliancy subset from the POWER ISA 3.1, which does not
mention power10.

> 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.

MMA is indeed optional for Linux.
AFAICS, cryptography-related instructions are part of SIMD and should be
required for Linux.

-- 
Tulio Magno