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 14926 invoked from network); 7 Dec 2021 01:16:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Dec 2021 01:16:14 -0000 Received: (qmail 19892 invoked by uid 550); 7 Dec 2021 01:16:12 -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 19872 invoked from network); 7 Dec 2021 01:16:12 -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=lRdTCA30pT3fpMkwAqmeKRq+mp2f1RfIZiGDWka5wjc=; b=Zv0tYeUtxnicKubWNIB5Wq/8NqgpQpEarGKyw0HZvcFzNJsbVzLJ0yG1yckxuBHwEt u0CC+bk1uUECV51B3qQol45tZiXXFazh2JZ1GwbmlcVfofsKFjIw8IjO5gmlh7N82OJR N/i83qWX+mtOZmx2D4xqv78P8wlH0h4lC/huinRldfdmTYyLXBz5tqNybdSSeEoHsTs+ E6CI40GrmEqUalNx83pVwhogqmwJPzXi7MmwpNSFdxeiXn6sZukTI8r7kmdkLXQpmPaj /f9ZUzAxQvV7udMAgKoYICQ+4OOj8qf+r8M3jGgwNjCYbzePzHO5+IQyRyH1bLANfH+I jcAg== 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=lRdTCA30pT3fpMkwAqmeKRq+mp2f1RfIZiGDWka5wjc=; b=3kN0i3zseIeBACT+PksNsUJ1MTPMWyTwBUESD8Q7GJs8YHIXgk/XbdaOfCM2WTsynT nrA5U4XrDxTrwYcL+ACA9Ljb6QzUj/0R718nd6uOkar6NVIdyxp7kKKcbvfsVHDC6haW WyU2YpegCd1CSa5zbDh6PbcKMoxKEDWEfbBDZG3WkWgHrpjWe2+g3seYn2Lf5MKGJoZ6 xL11MEjckDVK3L3rnrNH2CDu25HgNbgio1TKXmg4vaYAyypiYBazA8jkgL7G/YBeqaPP 9Ww2aSeK9vTNc3nd0cRwpqaD+n82Ue9l2q2mJsEFxi42sL8Za2vpGPPnAZlNyc/Aa4uG uiYg== X-Gm-Message-State: AOAM532wNYK2XWNckrGRw+7Tj3v9CmbOjPtgHGcP2Bz9aTRY8cYEOrqd hqWF3LRXUigf3l9IGfc/NS3FB1LmBgYMIwnNrc2rJT1R X-Google-Smtp-Source: ABdhPJwbguoqdjTDMRKo5K4u/QLCWXjUzYUSw6eBwxxPtWLOmNcaknNszgOzGVrwi+CnKPrLLNWft/BtQzzUul8MDB8= X-Received: by 2002:a05:6102:224f:: with SMTP id e15mr40247709vsb.81.1638839758824; Mon, 06 Dec 2021 17:15: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> In-Reply-To: <20211207005940.GK7074@brightrain.aerifal.cx> From: David Edelsohn Date: Mon, 6 Dec 2021 20:15:48 -0500 Message-ID: To: musl@lists.openwall.com Cc: 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 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, David