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-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B4E8020248 for ; Mon, 15 Apr 2019 20:24:25 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=v3IZ pNDWK/41c0ckuIX37siKiZhh1Qs1ye+f2rdDk+2xyNXDIejR05sXZznfYP5RwM4V WFxLe1qhZb13r31AXJhZSQY/K26TEM6I1ACBduV4CMwVJEmGzi41aVdmxYFxL8Qy d4Niw8HKAXaCcL9EHSq6yZ/ztgWx+TbCKnGg1Ag= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=juwVy7ejzJ 066KosivG42DMTEOc=; b=j+a7JwBF2tJ44fIUM629xfDyg8DMLZ2An1Yo1CXSBM qfpg1GbOxdQNnVNynOJJ2p6HZn8xm/29r/w/Pl3RSwK+d5TC68pXwNAjmJlDbc8Z ft2xrSA5APe9/7EZqXcT7/+g050QBaF6cWAaEsrRgA4F6uQ32Iflk1q7WddydiLl c= Received: (qmail 79046 invoked by alias); 15 Apr 2019 20:24:23 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 78960 invoked by uid 89); 15 Apr 2019 20:24:15 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: smtpout1.mo803.mail-out.ovh.net Date: Mon, 15 Apr 2019 17:23:56 -0300 From: "Gabriel F. T. Gomes" To: Adhemerval Zanella CC: Joseph Myers , Subject: Re: [PATCH 01/28] powerpc: Use generic fabs{f} implementations Message-ID: <20190415202356.7cltpw3akrcxjv6e@tereshkova> References: <20190329133529.22523-1-adhemerval.zanella@linaro.org> <20190329133529.22523-2-adhemerval.zanella@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Ovh-Tracer-Id: 16744664890303958729 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrvdelgddugeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm On Wed, Apr 03 2019, Adhemerval Zanella wrote: > > > On 02/04/2019 03:04, Joseph Myers wrote: > > On Fri, 29 Mar 2019, Adhemerval Zanella wrote: > > > >> Since be2e25bbd78f9fdf the generic ieee754 implementation uses > >> compiler builtin which generates fabs{f} for all supported targets. > > > > One reason for the existing version might be a microoptimization for code > > size to make the float and double versions aliases, as permitted by the > > ABIs and instruction set in this case. (This is not an objection to this > > patch.) > > > > Indeed powerpc does such microoptimizations for some implementations, but The code generated by these functions is as follows (on powerpc64le): Before the patch: 000000000004dac0 : 4dac0: 0e 00 4c 3c addis r2,r12,14 4dac4: 40 9b 42 38 addi r2,r2,-25792 4dac8: 10 0a 20 fc fabs f1,f1 4dacc: 20 00 80 4e blr After the patch: 000000000004dac0 : 4dac0: 10 0a 20 fc fabs f1,f1 4dac4: 20 00 80 4e blr (this is true when --enable-stack-protector is not in use, or when it is set to strong, as is the case for the distros I checked (Debian, Fedora and OpenSuse); when set to all, there would be a lot more differences before and after the patch, as the assembly implementation wouldn't get stack protection code, but that's not a problem, imo). (also, the absence of the TOC-setup code is fine, as the function does not need anything from the TOC). > if the idea is indeed to push such optimizations couldn't add on generic > implementation though a flag defined in arch-specific headers? Given the size of these functions, I believe that this is not worth the effort, and I believe this patch is OK as is. Reviewed-by: Gabriel F. T. Gomes