From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13372 invoked from network); 8 Dec 2021 11:06:22 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 8 Dec 2021 11:06:22 -0000 Received: (qmail 7469 invoked by uid 550); 8 Dec 2021 11:06:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13560 invoked from network); 8 Dec 2021 08:43:20 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.tintel.eu 85110443B995 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-ipv6.be; s=502B7754-045F-11E5-BBC5-64595FD46BE8; t=1638952988; bh=7+cbc3qMNchmJ4LCB5z4VGB5mgUNiGFGn+XGW89dGkw=; h=To:From:Message-ID:Date:MIME-Version; b=g0qXhFzRL6jIm+7V3FamtQvuwIBPmjkqkPCV4lJ1QzE2hgRzjq9cGb1dQGHW4sNg2 YdKo7xlsqjyRghEZ4SVnPNByjvVFj+B0VDn5849y+vs27FETutz3kQXEeuyyFFpzaG D68lWCBcR8w9bdv0MxBHmp9DPryHOnQUyUzLmGLs= X-Virus-Scanned: amavisd-new at mail.tintel.eu To: Rich Felker Cc: musl@lists.openwall.com References: <20211206234358.2174444-1-stijn@linux-ipv6.be> <87tufljlmv.fsf@oldenburg.str.redhat.com> <20211207005940.GK7074@brightrain.aerifal.cx> From: Stijn Tintel Message-ID: Date: Wed, 8 Dec 2021 10:43:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211207005940.GK7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [musl] [PATCH] ppc64: check for AltiVec in setjmp/longjmp On 7/12/2021 02:59, Rich Felker wrote: > On Tue, Dec 07, 2021 at 01:37:12AM +0100, Florian Weimer wrote: >> * Stijn Tintel: >> >>> diff --git a/src/setjmp/powerpc64/setjmp.s b/src/setjmp/powerpc64/setjmp.s >>> index 37683fda..32853693 100644 >>> --- a/src/setjmp/powerpc64/setjmp.s >>> +++ b/src/setjmp/powerpc64/setjmp.s >>> @@ -69,7 +69,17 @@ __setjmp_toc: >>> stfd 30, 38*8(3) >>> stfd 31, 39*8(3) >>> >>> - # 5) store vector registers v20-v31 >>> + # 5) store vector registers v20-v31 if hardware supports AltiVec >>> + mflr 0 >>> + bl 1f >>> + .hidden __hwcap >>> + .long __hwcap-. >>> +1: mflr 4 >> This de-balances the return stack and probably has quite severe >> performance impact. The ISA manual says to use >> >> bcl 20,31,$+4 >> >> and you'll have to store the __hwcap offset somewhere else. > To begin with, let's change the .s files to .S files and put the whole > branch logic inside #ifndef __ALTIVEC__ so that it does not impact > normal builds with an ISA level where Altivec can be assumed to be > present. > > I'm not sufficiently familiar with the PowerPC ISA to know how bcl > works, but if there's a less expensive solution along those lines > that's compatible with all ISA levels, by all means let's use it. The > same could be done for powerpc-sf (32-bit) and its SPE branches, too. > > Also the add and lwz can be used into lwzx (indexed load). > The code for ppc64 uses ld after add, not lwz. This is required to make it work on both big and little endian systems. We therefore cannot use lwzx, but have to use ldx. Stijn