From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0844C3F68F for ; Thu, 16 Jan 2020 19:47:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 754DB2073A for ; Thu, 16 Jan 2020 19:47:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579204074; bh=iWPOEPrLhN/0dUzUlwpw4/5CopjoSgUDgsorKgvcJmw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=rBDFz4B5Bu81YVEnna0K1PD4V2gfiVwYrInntQ3IS+OfCkYEVD6HL9Wo58QpVb2Xe 7Op/j5nr1Q9elhjYY4S2p6Nhag+oTBfffl0Ax/4CPlKYalDqms+p+otyfjX2WLc6C2 NVTIeTZZdNhga1APeXI7pLuUhhArKFYrNDBFscy8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729613AbgAPTrx (ORCPT ); Thu, 16 Jan 2020 14:47:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:42752 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729504AbgAPTrv (ORCPT ); Thu, 16 Jan 2020 14:47:51 -0500 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 219B1214AF for ; Thu, 16 Jan 2020 19:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579204070; bh=iWPOEPrLhN/0dUzUlwpw4/5CopjoSgUDgsorKgvcJmw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZBNmytBWuC0U8dtoZhF+ykaCrw12X24OzwI/4jlMPsTBRD4Skon1q/5BmRHCR7j36 U0SG46PBe9dZfmajYfQMP3/t6SsA/c/cTCxLI/yJ5fRxBdrzdYEx5a5LO34zOO6yIp MHsX6faaZ9XilvurLWm/Gziak4DDpI+m16cZOi68= Received: by mail-wr1-f49.google.com with SMTP id z3so20428981wru.3 for ; Thu, 16 Jan 2020 11:47:50 -0800 (PST) X-Gm-Message-State: APjAAAU8zwKkbvKu0TJRIdlx5OyP8eibnXd0ctEC+v3/VOgyyUsG1EVN /h5XwuBuPQD/9oB+foYWiZZOQ4L6k8JbaklHcdBt9A== X-Google-Smtp-Source: APXvYqz0S0n0mRf01AI9EVOJj9fh0guO9GsXoYIoeeHWqI3bcsdwUWPoJm22gBkYEqJCyt4y4xlERS5rQnr9jvHcuRE= X-Received: by 2002:adf:ebc6:: with SMTP id v6mr4976488wrn.75.1579204068445; Thu, 16 Jan 2020 11:47:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Lutomirski Date: Thu, 16 Jan 2020 11:47:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v4 10/11] lib: vdso: Allow arches to override the ns shift operation To: Christophe Leroy Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , nathanl@linux.ibm.com, Arnd Bergmann , Thomas Gleixner , Vincenzo Frascino , Andrew Lutomirski , LKML , linuxppc-dev , linux-arm-kernel , "open list:MIPS" , X86 ML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy wrote: > > On powerpc/32, GCC (8.1) generates pretty bad code for the > ns >>= vd->shift operation taking into account that the > shift is always < 32 and the upper part of the result is > likely to be nul. GCC makes reversed assumptions considering > the shift to be likely >= 32 and the upper part to be like not nul. > > unsigned long long shift(unsigned long long x, unsigned char s) > { > return x >> s; > } > > results in: > > 00000018 : > 18: 35 25 ff e0 addic. r9,r5,-32 > 1c: 41 80 00 10 blt 2c > 20: 7c 64 4c 30 srw r4,r3,r9 > 24: 38 60 00 00 li r3,0 > 28: 4e 80 00 20 blr > 2c: 54 69 08 3c rlwinm r9,r3,1,0,30 > 30: 21 45 00 1f subfic r10,r5,31 > 34: 7c 84 2c 30 srw r4,r4,r5 > 38: 7d 29 50 30 slw r9,r9,r10 > 3c: 7c 63 2c 30 srw r3,r3,r5 > 40: 7d 24 23 78 or r4,r9,r4 > 44: 4e 80 00 20 blr > > Even when forcing the shift with an &= 31, it still considers > the shift as likely >= 32. > > Define a vdso_shift_ns() macro that can be overriden by > arches. Would mul_u64_u64_shr() be a good alternative? Could we adjust it to assume the shift is less than 32? That function exists to benefit 32-bit arches. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F663C33CAF for ; Thu, 16 Jan 2020 21:07:43 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ABD1320661 for ; Thu, 16 Jan 2020 21:07:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZBNmytBW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABD1320661 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47zGx831PlzDr10 for ; Fri, 17 Jan 2020 08:07:40 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=luto@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=default header.b=ZBNmytBW; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 47zF944n6xzDqZW for ; Fri, 17 Jan 2020 06:47:52 +1100 (AEDT) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 098B12077C for ; Thu, 16 Jan 2020 19:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579204070; bh=iWPOEPrLhN/0dUzUlwpw4/5CopjoSgUDgsorKgvcJmw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZBNmytBWuC0U8dtoZhF+ykaCrw12X24OzwI/4jlMPsTBRD4Skon1q/5BmRHCR7j36 U0SG46PBe9dZfmajYfQMP3/t6SsA/c/cTCxLI/yJ5fRxBdrzdYEx5a5LO34zOO6yIp MHsX6faaZ9XilvurLWm/Gziak4DDpI+m16cZOi68= Received: by mail-wr1-f52.google.com with SMTP id z7so20368258wrl.13 for ; Thu, 16 Jan 2020 11:47:49 -0800 (PST) X-Gm-Message-State: APjAAAXlFwub5XVdv3M7+DQfJte5Lkv7lU9yMKEixSM6Pk4PZjE01lH9 oY475MgkLdrh2NbOnjbPYZhEIeVqSogFH4A0v15ywg== X-Google-Smtp-Source: APXvYqz0S0n0mRf01AI9EVOJj9fh0guO9GsXoYIoeeHWqI3bcsdwUWPoJm22gBkYEqJCyt4y4xlERS5rQnr9jvHcuRE= X-Received: by 2002:adf:ebc6:: with SMTP id v6mr4976488wrn.75.1579204068445; Thu, 16 Jan 2020 11:47:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Lutomirski Date: Thu, 16 Jan 2020 11:47:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v4 10/11] lib: vdso: Allow arches to override the ns shift operation To: Christophe Leroy Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: nathanl@linux.ibm.com, Arnd Bergmann , X86 ML , LKML , "open list:MIPS" , Paul Mackerras , Andrew Lutomirski , Thomas Gleixner , Vincenzo Frascino , linuxppc-dev , linux-arm-kernel Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy wrote: > > On powerpc/32, GCC (8.1) generates pretty bad code for the > ns >>= vd->shift operation taking into account that the > shift is always < 32 and the upper part of the result is > likely to be nul. GCC makes reversed assumptions considering > the shift to be likely >= 32 and the upper part to be like not nul. > > unsigned long long shift(unsigned long long x, unsigned char s) > { > return x >> s; > } > > results in: > > 00000018 : > 18: 35 25 ff e0 addic. r9,r5,-32 > 1c: 41 80 00 10 blt 2c > 20: 7c 64 4c 30 srw r4,r3,r9 > 24: 38 60 00 00 li r3,0 > 28: 4e 80 00 20 blr > 2c: 54 69 08 3c rlwinm r9,r3,1,0,30 > 30: 21 45 00 1f subfic r10,r5,31 > 34: 7c 84 2c 30 srw r4,r4,r5 > 38: 7d 29 50 30 slw r9,r9,r10 > 3c: 7c 63 2c 30 srw r3,r3,r5 > 40: 7d 24 23 78 or r4,r9,r4 > 44: 4e 80 00 20 blr > > Even when forcing the shift with an &= 31, it still considers > the shift as likely >= 32. > > Define a vdso_shift_ns() macro that can be overriden by > arches. Would mul_u64_u64_shr() be a good alternative? Could we adjust it to assume the shift is less than 32? That function exists to benefit 32-bit arches. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96594C33CAF for ; Thu, 16 Jan 2020 19:47:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6402520730 for ; Thu, 16 Jan 2020 19:47:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CkxibIeY"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZBNmytBW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6402520730 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=N+7rf7bDn51WlVCO+b5UaubJMnByBFK9lOspc0JLL6k=; b=CkxibIeY0QuFhP 9S5Wcq6BHt0vLxozB+hOHi0p/DkDJcPMkm3qKczzkBdpzmOizUY+aWGSJXP0yoDRps55fjRjzj7Tx UklX9Ihn6Jrezt+pQ04Eyj3WJnfRq42eaULxNa1kHn5jkFXulbJSDvS0ZpYz22c1xLJyauhTE6A9h yBVj6c7LzsqwQvD8T1CDeoS+jTstNDKsI4zn4QmSyD1Nr56KsUg1iCirx65Cdnpjh3GCgCf6OAS2Z rBOVgZXdCZGONTnbKnLHjmg7jTDqzcjcoUbmveeGTCszGfEh8UVQEBVTfkjwCPjMDK2cNb1JSZVJx 27iXvCBGfGTqNnrAPheg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1isB7S-0008GE-1H; Thu, 16 Jan 2020 19:47:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1isB7P-0008Fj-0k for linux-arm-kernel@lists.infradead.org; Thu, 16 Jan 2020 19:47:52 +0000 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 07A872077B for ; Thu, 16 Jan 2020 19:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579204070; bh=iWPOEPrLhN/0dUzUlwpw4/5CopjoSgUDgsorKgvcJmw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZBNmytBWuC0U8dtoZhF+ykaCrw12X24OzwI/4jlMPsTBRD4Skon1q/5BmRHCR7j36 U0SG46PBe9dZfmajYfQMP3/t6SsA/c/cTCxLI/yJ5fRxBdrzdYEx5a5LO34zOO6yIp MHsX6faaZ9XilvurLWm/Gziak4DDpI+m16cZOi68= Received: by mail-wr1-f41.google.com with SMTP id j42so20381609wrj.12 for ; Thu, 16 Jan 2020 11:47:49 -0800 (PST) X-Gm-Message-State: APjAAAVu5YdAtY2veek4zcZeusUQKI5Sc5f7q8PnnvWy4kIwFi3W8pm3 K8YqTj9kw+W7vZOtjwqXAZPizFs8c8etoI0HeEFgQw== X-Google-Smtp-Source: APXvYqz0S0n0mRf01AI9EVOJj9fh0guO9GsXoYIoeeHWqI3bcsdwUWPoJm22gBkYEqJCyt4y4xlERS5rQnr9jvHcuRE= X-Received: by 2002:adf:ebc6:: with SMTP id v6mr4976488wrn.75.1579204068445; Thu, 16 Jan 2020 11:47:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Lutomirski Date: Thu, 16 Jan 2020 11:47:36 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v4 10/11] lib: vdso: Allow arches to override the ns shift operation To: Christophe Leroy X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200116_114751_077725_6665E8AB X-CRM114-Status: GOOD ( 12.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: nathanl@linux.ibm.com, Arnd Bergmann , Benjamin Herrenschmidt , X86 ML , LKML , "open list:MIPS" , Paul Mackerras , Andrew Lutomirski , Michael Ellerman , Thomas Gleixner , Vincenzo Frascino , linuxppc-dev , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy wrote: > > On powerpc/32, GCC (8.1) generates pretty bad code for the > ns >>= vd->shift operation taking into account that the > shift is always < 32 and the upper part of the result is > likely to be nul. GCC makes reversed assumptions considering > the shift to be likely >= 32 and the upper part to be like not nul. > > unsigned long long shift(unsigned long long x, unsigned char s) > { > return x >> s; > } > > results in: > > 00000018 : > 18: 35 25 ff e0 addic. r9,r5,-32 > 1c: 41 80 00 10 blt 2c > 20: 7c 64 4c 30 srw r4,r3,r9 > 24: 38 60 00 00 li r3,0 > 28: 4e 80 00 20 blr > 2c: 54 69 08 3c rlwinm r9,r3,1,0,30 > 30: 21 45 00 1f subfic r10,r5,31 > 34: 7c 84 2c 30 srw r4,r4,r5 > 38: 7d 29 50 30 slw r9,r9,r10 > 3c: 7c 63 2c 30 srw r3,r3,r5 > 40: 7d 24 23 78 or r4,r9,r4 > 44: 4e 80 00 20 blr > > Even when forcing the shift with an &= 31, it still considers > the shift as likely >= 32. > > Define a vdso_shift_ns() macro that can be overriden by > arches. Would mul_u64_u64_shr() be a good alternative? Could we adjust it to assume the shift is less than 32? That function exists to benefit 32-bit arches. --Andy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel