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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18423 invoked from network); 7 Dec 2021 01:45:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Dec 2021 01:45:12 -0000 Received: (qmail 5762 invoked by uid 550); 7 Dec 2021 01:45:10 -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 5742 invoked from network); 7 Dec 2021 01:45:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wmRTlWye1zCiQB6bLkDaqIZIBi6poSmFVgYZB7KqTMY=; b=YNmwrhowsoI+XymuT2RXsBOC39p+mzREsRDE+xt//ace+UZ4tpdRm+WLjGCtNlSCRQ I/bNGO7pBaAbHu4ZIGXjfRr9M7zkbPb6N2HYvbESYmi4p2zvBoUnKaxJOxNWMDF7gsAT tnwokA+0htVncYZKjp4IT1m66bD+dmWO9v8qqG+EkPNWCpWkpwdv/MOR5TRPTxA2NQyk eLQbGJjWgHmw/n4fmfGMtSYXB8MHpEYOFJDWo+4lyYsRfjEezT4AdG0tXWJpJYfHuGSk Wi3BaNc6DbADX+Fv3ApMhU/B2a/01me/2ql8nMFAOuyrHqemBC/tvpAMwSgDePW6ZTPm jLCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wmRTlWye1zCiQB6bLkDaqIZIBi6poSmFVgYZB7KqTMY=; b=N1wtXzWeM1VXQPn3Ta4nqFTEP5j3SbgATqmcVfNUerAQQAxn+g6lVk+yjVFHuO7MNr HjAkwherUOm+S5NPx4sorhvD9uWPtPaPZq2wC27EXHpjToVCqfG0wATAUlIo3huqGHtX KRTsc7IxnIwMQQopIirpm4DzWh8aLxsCQ7YKQrS4CboymGGVvxEf9aTNOs2/9oVbvEDk 4gQxcRlXiarPInKxtiTWTUzUzknGSR/yFzI8HkQNzQgdNBPi+VQaM0gnYs8opuUNis24 eK649WOF1EejzBpV19ODdrqrXfiViw+gfvQBvHAovvxHWx75+OYZpfjnLAefIO9AyKyV uB8Q== X-Gm-Message-State: AOAM532J0vMVtB4M/4PZ23A2381dJLBIbMzdsKnPX8l90jM+tLHcgpk1 SjFZKqpiYmiqhyitFfFmmVkWdoGS/Q9TYAJ0YX5c2a99 X-Google-Smtp-Source: ABdhPJwgbxE+Q401jSyBpLf/lmiHwaztwC94Bc2yekgXIFX0lpRMEAFTa5pD968PnWlBxpOsQTC0JkQgGf+mSwMjzHE= X-Received: by 2002:a05:6122:114c:: with SMTP id p12mr46995382vko.21.1638841498231; Mon, 06 Dec 2021 17:44:58 -0800 (PST) MIME-Version: 1.0 References: <20211206234358.2174444-1-stijn@linux-ipv6.be> <87tufljlmv.fsf@oldenburg.str.redhat.com> <20211207005940.GK7074@brightrain.aerifal.cx> <20211207013930.GM7074@brightrain.aerifal.cx> In-Reply-To: <20211207013930.GM7074@brightrain.aerifal.cx> From: David Edelsohn Date: Mon, 6 Dec 2021 20:44:47 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com, Florian Weimer , Stijn Tintel Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] [PATCH] ppc64: check for AltiVec in setjmp/longjmp On Mon, Dec 6, 2021 at 8:39 PM Rich Felker wrote: > > On Mon, Dec 06, 2021 at 08:15:48PM -0500, David Edelsohn wrote: > > On Mon, Dec 6, 2021 at 7:59 PM 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. > > > > bl = branch and link > > bcl = branch conditional and link > > > > link means place the next instruction address in the link register. > > Normally a branch and link would be used for a matching "return" > > instruction, but in this case it is being used to compute a position > > independent code address. As Florian correctly points out, the "bl" > > will corrupt the link stack in the processor used to predict return > > addresses and the recommended sequence is the one that he suggests. > > > > bcl 20,31,addr > > > > which means branch always and, because the condition register bits are > > irrelevant, a special value that instructs the processor to not push > > the address onto the link stack so that the "calls" and "returns" > > remain matched. > > Thanks. Am I correct in understanding then that we don't need $+4, but > can instead use the 1f just as now, with inline .long __hwcap-. -- in > other words that "bcl 20,31," is a drop-in replacement for "bl" > without the link stack impact? It should work, but it's slightly preferred to use $+4 because one explicitly wants the address of the next instruction and labels of the form "1f" are not supported by all assemblers. Thanks, David