Message ID | 20220901032407.23751-1-guojiufu@linux.ibm.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:ecc5:0:0:0:0:0 with SMTP id s5csp57242wro; Wed, 31 Aug 2022 20:25:09 -0700 (PDT) X-Google-Smtp-Source: AA6agR7Wv8zD2sQ1Bk5f35y6VrdHxJoYpJTTgxbywcZpm45zWD2VVouAltndSisGnzvi4VDj953I X-Received: by 2002:a17:907:6d06:b0:741:59d4:77fb with SMTP id sa6-20020a1709076d0600b0074159d477fbmr14627888ejc.335.1662002709735; Wed, 31 Aug 2022 20:25:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662002709; cv=none; d=google.com; s=arc-20160816; b=MctKEcbMFRW8W0/NthyEpuOVEsA4Ww1yT9mzrSjjW8jr7RKMa94lI6PpverKx12+s+ CMIMIFTLscotRzCvVLQeFsgufF7TT6rTf3GQ5nZyE0Tvf2cBNxVWyLthhVguV9/hpgOO vrsnGBtUJw0zxpYjyv0QrvbxkIyka79OWhTHPZnGGGBdQeIZYwbzjqm+5ADkXWcEhJJt HdHwIiZY7XfTZVuQXIInb5H1k0dbgyaN4thkbH0WNf9KwvrL2e/M9uwSC5rIP6uorGjK Dwa5uTLIGf1k6k5CJFi7FVa8ODtFJ/h8fUIrzTxiq00ZH+9T4f+EIJ8Gz9zM4lU88lJM mCPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:reply-to:from:list-subscribe:list-help :list-post:list-archive:list-unsubscribe:list-id:precedence :message-id:date:subject:to:dmarc-filter:delivered-to:dkim-signature :dkim-filter; bh=SgMTTKeetj27fYbITQRxzeDVjnWSdOmgFj2K1IWa7CQ=; b=kr0gMCrU4VRKMJ/ioQjsQCJDiw+ZBR7RyQyiglcnTB12jeBi64TIdHELsdSglNZ8IF yd6zMoETb/MWyz/8gfsw26+8hyL6+iQYaLqIs1MJqioBz7c7/EQZAP2VWqWptcYjJHbE dl+f4JGHz/wVVZbH2uX3UhBXD1AiS3cQM/HeRuph379ACA5MqOLTVRk1gxprR+mCG2Xf DSGQqgq9WXmq/BBP6bc0cB40Wb7A9nyOUVUEJQBuw+I4MKQaYYVCg5d8JtNLWbBn/y8U qVB1XwiD+zNzqTRZ41PmxRmsXqyTvkuWpMqhDzdz8iWA/rGyUnGXJyiVTMRWJZFlDP+8 YDfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=pI4FaRXM; 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 hw19-20020a170907a0d300b0073832d0cdfdsi8968235ejc.649.2022.08.31.20.25.09 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 20:25:09 -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=pI4FaRXM; 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 D45AF3834F28 for <ouuuleilei@gmail.com>; Thu, 1 Sep 2022 03:25:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D45AF3834F28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662002700; bh=SgMTTKeetj27fYbITQRxzeDVjnWSdOmgFj2K1IWa7CQ=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=pI4FaRXMncPmmxCF0fRnJz3VEvHGdDEbEKATnpvPpT++RGtNOr+gDsfKlGxPRmnab sBgz+fq30qsSRP8HTLaSVIlb728JbgoObQeAcluDHXhQw25uSXN/ueCKGgpWNsZuah pZZs8wyJZm8FbmrrWwa4zq+xN6ri6HM63aIGBr8w= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 0FD973834F27; Thu, 1 Sep 2022 03:24:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0FD973834F27 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2812uKfG030701; Thu, 1 Sep 2022 03:24:15 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jamd3gyq3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Sep 2022 03:24:15 +0000 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 28130pm1018542; Thu, 1 Sep 2022 03:24:14 GMT Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jamd3gynq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Sep 2022 03:24:14 +0000 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2813NZ3M029877; Thu, 1 Sep 2022 03:24:11 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma02fra.de.ibm.com with ESMTP id 3j7aw8ve0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Sep 2022 03:24:11 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2813O8ne37749078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Sep 2022 03:24:08 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 72575A404D; Thu, 1 Sep 2022 03:24:08 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F087A4040; Thu, 1 Sep 2022 03:24:07 +0000 (GMT) Received: from pike.rch.stglabs.ibm.com (unknown [9.5.12.127]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 1 Sep 2022 03:24:07 +0000 (GMT) To: gcc-patches@gcc.gnu.org Subject: [PATCH 2/2] allow constant splitter run in split1 pass Date: Thu, 1 Sep 2022 11:24:07 +0800 Message-Id: <20220901032407.23751-1-guojiufu@linux.ibm.com> X-Mailer: git-send-email 2.17.1 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Jsu61FPJC4gwI3p31OczN3awlEVFxOPL X-Proofpoint-ORIG-GUID: X1mdRUsJ1Sx895EtAtiKTmjy-7STUHzp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-09-01_01,2022-08-31_03,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 phishscore=0 clxscore=1015 adultscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2209010011 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, 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: Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jiufu Guo <guojiufu@linux.ibm.com> Cc: meissner@linux.ibm.com, dje.gcc@gmail.com, segher@kernel.crashing.org, linkw@gcc.gnu.org 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?1742736153509343467?= X-GMAIL-MSGID: =?utf-8?q?1742736153509343467?= |
Series |
[1/2] Using pli(paddi) and rotate to build 64bit constants
|
|
Commit Message
Jiufu Guo
Sept. 1, 2022, 3:24 a.m. UTC
Hi, Currently, these two splitters (touched in this patch) are using predicate `int_reg_operand_not_pseudo`, then they work in split2 pass after RA in most times, and can not run before RA. It would not be a bad idea to allow these splitters before RA. Then more passes (between split1 and split2) could optimize the emitted instructions. And if splitting before RA, for these constant splitters, we may have more freedom to create pseduo to generate more parallel instructions. For the example in the leading patch [PATCH 1/2]: pli+plit+rldimi would be better than pli+sldi+paddi. Test this patch with spec, we could see performance gain some times; while the improvement is not stable and woud caused by the patch indirectly. This patch pass boostrap and regtest on ppc64le(includes p10). Is it ok for trunk? Thanks for comments! BR, Jeff(Jiufu) gcc/ChangeLog: * config/rs6000/rs6000.md (const splitter): Update predicate. --- gcc/config/rs6000/rs6000.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Hi! On Thu, Sep 01, 2022 at 11:24:07AM +0800, Jiufu Guo wrote: > Currently, these two splitters (touched in this patch) are using predicate > `int_reg_operand_not_pseudo`, then they work in split2 pass after RA in > most times, and can not run before RA. > > It would not be a bad idea to allow these splitters before RA. Then more > passes (between split1 and split2) could optimize the emitted instructions. The splitters can be used earlier even. For example, often combine will use them. > And if splitting before RA, for these constant splitters, we may have more > freedom to create pseduo to generate more parallel instructions. > > For the example in the leading patch [PATCH 1/2]: pli+plit+rldimi would be > better than pli+sldi+paddi. Yes. If you split after reload you have to do all local optimisations (that would have been done in earlier passes) manually. And all more global ones (involving just one or two more insns already) are essentially impossible to do. Splitting after reload is necessary in some cases. For example, all the integer "dot" insns split to the base insn and an explicit compare, if for some reason RA did not get cr0 here. Importantly, this happens very seldomly: RA knows it is two insns instead of one, and it chooses accordingly. Also it *has* to be after reload, it directly depends on what RA chose to do. Splitting dependent on if a VSR or a GPR (pair) was used is a losing proposition. It usually costs much more than it can gain. > gcc/ChangeLog: > > * config/rs6000/rs6000.md (const splitter): Update predicate. * config/rs6000/rs6000.md (splitter for set to and_mask constants): Use int_reg_operand (instead of int_reg_operand_not_pseudo). (splitter for multi-insn constant loads): Ditto. You should mention the changed to *both* splitters. For nameless splitters it helps if you can describe it a bit. This is hard, yes :-/ Okay for trunk like that. Thanks! Segher
Segher Boessenkool <segher@kernel.crashing.org> writes: > Hi! > > On Thu, Sep 01, 2022 at 11:24:07AM +0800, Jiufu Guo wrote: >> Currently, these two splitters (touched in this patch) are using predicate >> `int_reg_operand_not_pseudo`, then they work in split2 pass after RA in >> most times, and can not run before RA. >> >> It would not be a bad idea to allow these splitters before RA. Then more >> passes (between split1 and split2) could optimize the emitted instructions. > > The splitters can be used earlier even. For example, often combine will > use them. Oh, yes! > >> And if splitting before RA, for these constant splitters, we may have more >> freedom to create pseduo to generate more parallel instructions. >> >> For the example in the leading patch [PATCH 1/2]: pli+plit+rldimi would be >> better than pli+sldi+paddi. > > Yes. If you split after reload you have to do all local optimisations > (that would have been done in earlier passes) manually. And all more > global ones (involving just one or two more insns already) are > essentially impossible to do. > > Splitting after reload is necessary in some cases. For example, all the > integer "dot" insns split to the base insn and an explicit compare, if > for some reason RA did not get cr0 here. Importantly, this happens very > seldomly: RA knows it is two insns instead of one, and it chooses > accordingly. Also it *has* to be after reload, it directly depends on > what RA chose to do. > > Splitting dependent on if a VSR or a GPR (pair) was used is a losing > proposition. It usually costs much more than it can gain. > Thanks for your detailed explain which makes more reasonable! >> gcc/ChangeLog: >> >> * config/rs6000/rs6000.md (const splitter): Update predicate. > > * config/rs6000/rs6000.md (splitter for set to and_mask constants): > Use int_reg_operand (instead of int_reg_operand_not_pseudo). > (splitter for multi-insn constant loads): Ditto. > > You should mention the changed to *both* splitters. For nameless > splitters it helps if you can describe it a bit. This is hard, yes :-/ > Thanks for your always helpful comments! BR, Jeff(Jiufu) > Okay for trunk like that. Thanks! > > > Segher
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index 1367a2cb779..ec39676f628 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -9641,7 +9641,7 @@ (define_insn "*movdi_internal64" ; Some DImode loads are best done as a load of -1 followed by a mask ; instruction. (define_split - [(set (match_operand:DI 0 "int_reg_operand_not_pseudo") + [(set (match_operand:DI 0 "int_reg_operand") (match_operand:DI 1 "const_int_operand"))] "TARGET_POWERPC64 && num_insns_constant (operands[1], DImode) > 1 @@ -9659,7 +9659,7 @@ (define_split ;; When non-easy constants can go in the TOC, this should use ;; easy_fp_constant predicate. (define_split - [(set (match_operand:DI 0 "int_reg_operand_not_pseudo") + [(set (match_operand:DI 0 "int_reg_operand") (match_operand:DI 1 "const_int_operand"))] "TARGET_POWERPC64 && num_insns_constant (operands[1], DImode) > 1" [(set (match_dup 0) (match_dup 2))