From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D142F1F66F for ; Tue, 3 Nov 2020 15:15:12 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C945C3854833; Tue, 3 Nov 2020 15:15:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C945C3854833 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1604416511; bh=n/BWj37Ln6LzdpaFi2208UJSkpEvqzUzCUq0XmpmsBs=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=KsjJfTqQ73uKLYtzgK9icAme/F64Kv3a7rH/v8BVtblz1CdorAQbnnHLgDiCC9lPC dQYN9H5ORXoyC5KN0EY8DopbWMy8sww3Fl7XGV/ril0xJItTaRpQocnWVatEGYRNJ4 q4WJAoQHMORAjwgcPrJ4IC6vMoY8JowGtJuupX/E= Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) by sourceware.org (Postfix) with ESMTPS id 794C23854833 for ; Tue, 3 Nov 2020 15:15:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 794C23854833 X-Sender-Id: dreamhost|x-authsender|tuliom@ascii.art.br Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7BBE0542496; Tue, 3 Nov 2020 15:15:05 +0000 (UTC) Received: from pdx1-sub0-mail-a19.g.dreamhost.com (100-96-5-167.trex.outbound.svc.cluster.local [100.96.5.167]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 59CCB5424AD; Tue, 3 Nov 2020 15:15:04 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|tuliom@ascii.art.br Received: from pdx1-sub0-mail-a19.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Tue, 03 Nov 2020 15:15:05 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|tuliom@ascii.art.br X-MailChannels-Auth-Id: dreamhost X-Celery-Cold: 2d79d25660178762_1604416504644_4073257257 X-MC-Loop-Signature: 1604416504644:2282234131 X-MC-Ingress-Time: 1604416504644 Received: from pdx1-sub0-mail-a19.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a19.g.dreamhost.com (Postfix) with ESMTP id ACF157F0C5; Tue, 3 Nov 2020 07:15:03 -0800 (PST) Received: from ascii.art.br (ip-138-255-24-246.isp.valenet.com.br [138.255.24.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: tuliom@ascii.art.br) by pdx1-sub0-mail-a19.g.dreamhost.com (Postfix) with ESMTPSA id EDAD67F4B9; Tue, 3 Nov 2020 07:14:56 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a19 To: Florian Weimer Subject: Re: [PATCH v2 3/3] powerpc64le: Add glibc-hwcaps support In-Reply-To: <874km8hxo7.fsf@oldenburg2.str.redhat.com> References: <87pn4zfgyh.fsf@linux.ibm.com> <874km8hxo7.fsf@oldenburg2.str.redhat.com> User-Agent: Notmuch/0.29.1 (http://notmuchmail.org) Emacs/26.3 (x86_64-redhat-linux-gnu) Date: Tue, 03 Nov 2020 12:14:51 -0300 Message-ID: <87mtzyfp5g.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Tulio Magno Quites Machado Filho via Libc-alpha Reply-To: Tulio Magno Quites Machado Filho Cc: , libc-alpha@sourceware.org, "Paul A. Clarke" Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Florian Weimer 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