Message ID | 20230427000528.C64CA20420@pchp3.se.axis.com |
---|---|
State | Repeat Merge |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp576800vqo; Wed, 26 Apr 2023 17:06:16 -0700 (PDT) X-Google-Smtp-Source: AKy350YklzDsiyqx+OAFbQDsQPLRIYJorXvD3zZBPKHFpQ+nBjpBBTt4s5Arz7mid/B9RbrTy42H X-Received: by 2002:a17:906:b2d7:b0:94a:5a9e:9da0 with SMTP id cf23-20020a170906b2d700b0094a5a9e9da0mr16899291ejb.77.1682553976239; Wed, 26 Apr 2023 17:06:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682553976; cv=none; d=google.com; s=arc-20160816; b=NldP2xIDOtuj/jAP/lvD7ly5ScQpdDEWEGzNmrD3voucuyLb6f0Z82edukJkCsszeP QULJiRZxptlTL5tEh9/Lap634Oo2Kos4FjMo9C2ylcqDguCgI4BmVusDaFyl6zAH9dGI at1XH92WI/Asyl46KXkBPcogEN5jVDwutJpHwPcLhMvOEFMNSGD7c+tzbfcnEA69Yvz+ vUyD8FDqGoL+IhyTmmclS5Dwk+WL4MTm7hYz0s5PSA1ENFB6ZFYTg1+5fm+qesHSRUJB AMVduTm2DRL8mVWBPZh4Oi7m5jzaa0jjlJ+mfJAA8rhJbdVc57C/q2V3dWWLJi+5yMd6 2hgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:date:message-id:cc :content-transfer-encoding:mime-version:subject:to:dmarc-filter :delivered-to:dkim-signature:dkim-filter; bh=FBiAswkyIj0bFsUZlYvXThzYmtBub0VmOG4AxlT9cSM=; b=Kb6KY9AiRowEZTTm+FYJh2DTEULjF+uq/uKKkOnIrHz0LNfZEom4HP9a2uGxeIhLdt rUmXgJSvVOjYAMbwaVyzTt9tZzOL+Q7bcfF/WJUtAW3rxM0nCyy3D9TLqOtd1aNVv2h4 RizPZrFIvRfCUVIIdTjC2AsoC6TmYf8ElwcRULdUaYynsiHb6Ajnwxi6N7HBsuj/YDFz fkB4UqI8JWeeT5tkT663XINW6o+ryfPyyJsimSYJqZcRMQ91q40tt6MK8TXyqmpszzDu 978+/nH9kjhiO62Kn4wpRjj5SXYUwcaFeGfX++gCOuCGBfi+lKjwVcYRPJDEyTfBXm7K eSng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=omfgCUMt; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id ks19-20020a170906f85300b0094f6b89f6a3si11658276ejb.364.2023.04.26.17.06.15 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 17:06:16 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=omfgCUMt; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C5E283858438 for <ouuuleilei@gmail.com>; Thu, 27 Apr 2023 00:06:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C5E283858438 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1682553974; bh=FBiAswkyIj0bFsUZlYvXThzYmtBub0VmOG4AxlT9cSM=; h=To:Subject:CC:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=omfgCUMtPMiXFEP1/rn2OamKK6J4+rG3n290qddu11lHoCep2GvKbZEV/u0ISc/PT Yz7aiT62FLoNi3sxgM10ZkzhDOwVS5Ymkun70KHEK+nOmoiUWgkeD1Po050mw8z3ab vMZi3Bu2asW3dEMuEbKG+QFH0Fr74PLJrn7KH8hs= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by sourceware.org (Postfix) with ESMTPS id 30B4B3858C62 for <gcc-patches@gcc.gnu.org>; Thu, 27 Apr 2023 00:05:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 30B4B3858C62 To: <gcc-patches@gcc.gnu.org> Subject: [committed] libgcc CRIS: Define TARGET_HAS_NO_HW_DIVIDE MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT CC: <nickc@redhat.com>, <paulkoning@comcast.net> Message-ID: <20230427000528.C64CA20420@pchp3.se.axis.com> Date: Thu, 27 Apr 2023 02:05:28 +0200 X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Hans-Peter Nilsson <hp@axis.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764285717943955649?= X-GMAIL-MSGID: =?utf-8?q?1764285717943955649?= |
Series |
[committed] libgcc CRIS: Define TARGET_HAS_NO_HW_DIVIDE
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | warning | Git am fail log |
Commit Message
Hans-Peter Nilsson
April 27, 2023, 12:05 a.m. UTC
Not many targets define this besides msp430, pdp1, xtensa, and arm compared to those that appear to unconditionally have a hardware division instruction (also, pdp11 and msp430 seem confused and should be empty instead of "1" and "(! TARGET_HWMULT)" - and having hardware multiplication doesn't have a bearing anyway even if that worked; see numbers below for an example). Heads-up maintainers of ports without hardware division (including conditionally, for multilibbed configurations)! -- >8 -- With this, execution time for e.g. __moddi3 go from 59 to 40 cycles in the "fast" case or from 290 to 200 cycles in the "slow" case (when the !TARGET_HAS_NO_HW_DIVIDE variant calls division and modulus functions for 32-bit SImode), as exposed by gcc.c-torture/execute/arith-rand-ll.c compiled for -march=v10. Unfortunately, it just puts a performance improvement "dent" of 0.07% in a arith-rand-ll.c-based performance test - where all loops are also reduced to 1/10. The size of every affected libgcc function is reduced to less than half and they are all now leaf functions. * config/cris/t-cris (HOST_LIBGCC2_CFLAGS): Add -DTARGET_HAS_NO_HW_DIVIDE. --- libgcc/config/cris/t-cris | 3 +++ 1 file changed, 3 insertions(+)
Comments
> On Apr 26, 2023, at 8:05 PM, Hans-Peter Nilsson <hp@axis.com> wrote: > > Not many targets define this besides msp430, pdp1, xtensa, > and arm compared to those that appear to unconditionally > have a hardware division instruction (also, pdp11 and > msp430 seem confused and should be empty instead of "1" ... How so, "confused"? The documentation says it should be defined, it doesn't say that it should be defined as empty. What goes wrong if it's defined as 1 rather than empty? The documentation is also somewhat misleading, because it says to define it if the hardware has no divide instruction. The more accurate statement is that it should be defined if the hardware has no 64 / 32 bit divide hardware support. pdp11.h points this out in a comment, because most pdp11s do have divide instructions but those are for 32 / 16 bits. paul
> From: Paul Koning <paulkoning@comcast.net> > Date: Wed, 26 Apr 2023 21:02:31 -0400 > > On Apr 26, 2023, at 8:05 PM, Hans-Peter Nilsson <hp@axis.com> wrote: > > > > Not many targets define this besides msp430, pdp1, xtensa, > > and arm compared to those that appear to unconditionally > > have a hardware division instruction (also, pdp11 and > > msp430 seem confused and should be empty instead of "1" ... > > How so, "confused"? The documentation says it should be > defined, it doesn't say that it should be defined as > empty. What goes wrong if it's defined as 1 rather than > empty? Only future edits, expecting action to follow as if it was a non-zero expression like many of the target macros. > The documentation is also somewhat misleading, because it > says to define it if the hardware has no divide > instruction. The more accurate statement is that it > should be defined if the hardware has no 64 / 32 bit > divide hardware support. pdp11.h points this out in a > comment, because most pdp11s do have divide instructions > but those are for 32 / 16 bits. That might be true, and I've heard patches are welcome. brgds, H-P
diff --git a/libgcc/config/cris/t-cris b/libgcc/config/cris/t-cris index b582974a42ee..e0020294be96 100644 --- a/libgcc/config/cris/t-cris +++ b/libgcc/config/cris/t-cris @@ -8,3 +8,6 @@ $(LIB2ADD): $(srcdir)/config/cris/arit.c echo "#define L$$name" > tmp-$@ \ && echo '#include "$<"' >> tmp-$@ \ && mv -f tmp-$@ $@ + +# Use an appropriate implementation when implementing DImode division. +HOST_LIBGCC2_CFLAGS += -DTARGET_HAS_NO_HW_DIVIDE