From patchwork Wed Nov 8 03:47:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lehua Ding X-Patchwork-Id: 16364 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp676301vqo; Tue, 7 Nov 2023 19:48:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IEsedmMwpQ0RZnMjioN99g0FLo0HB3tuFH+b5K3Fx99n1wX1DqRdDeJfH6ch/++11ULLJ5Z X-Received: by 2002:a05:620a:24d3:b0:775:9f94:1a7b with SMTP id m19-20020a05620a24d300b007759f941a7bmr637397qkn.0.1699415299150; Tue, 07 Nov 2023 19:48:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1699415299; cv=pass; d=google.com; s=arc-20160816; b=gCWHmT52eHcLL+yHWCohJGEWTpL04lnmzt+v5eV77eeX1K42L7kN5EWm/nqsB/Xaut XTUDKqIRtaoPMWEbh856LKdUSHgJtV40flS59hl4x6LpCUiFjwADgImOtO2Q4vtUgqb4 sbXiDHs4JUI0bNvT9XkXmmv1lkGQR94J92iD+/U3oQM4f81B1tE8l8E5yLYNcxllrhHR aDuQy4L+OzhmHYzfst7I3CCKhU5KHa5KTcvoR7fAvWzHetHd/PQhO5fUIqYwfLhsDphz 6W3XQTVpRg/yQ01HyuPpfolTZDJO97gflhKBogVyCllpRP2qFvb9gfMrHDzBwHQw8UZy BxxQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:feedback-id :content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:arc-filter:dmarc-filter:delivered-to; bh=hSWhacUL/AnNfGTrkakp9kZ9Ed+0B8WQj71oCuAvN0M=; fh=9Ok8HNl3eD0lUFF4nhUPZJmQfyAUbHnIPw/rSVNIfK0=; b=pHFEq0WCC+tUZi64S2RKv2DbWNCY1PXzR+dctFxI/VCO7ITtodj/oqPPJQFZ28yQ+1 czWHCXoX5PGNkkZjbXys3Xf8Ngr2JWZ6TATRAlRrUICAvDCHrTLQRJPLHpT5xC8WIiHn nfgRDSDq/Jae/Q/e6bc9Xl7RrW/d0zJXz5Nrs0WnXgCiJS2vNaQ0We9kDtoY+RVoWS7o F1POGtHHG/v0SYqWFFHKEn5vx4173hDDE/fDSGvOM2NuYOnEnhLgArNMbKgmnCzno8Ei GT6AlVsocrDndmaKN6EH3nZM2Vq5h58Unasay+2sqJx6KprCJMnDKQdXa6f5I7advDeW HZBw== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); 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" Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id m18-20020a05620a221200b00779f280eec8si757719qkh.752.2023.11.07.19.48.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 19:48:19 -0800 (PST) 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; arc=pass (i=1); 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" Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 10AB93858414 for ; Wed, 8 Nov 2023 03:48:18 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtpbgeu2.qq.com (smtpbgeu2.qq.com [18.194.254.142]) by sourceware.org (Postfix) with ESMTPS id D79543858D33 for ; Wed, 8 Nov 2023 03:47:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D79543858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivai.ai Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivai.ai ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D79543858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=18.194.254.142 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699415274; cv=none; b=T0B/G0O/+BeyDq4MyDgpI974RFO2oBvAg1S2rEij4qFI32cApc+EeoKQ5TaD6iwN+4vldztbPlfKEdAT+byg3XDOD+YngHX0lqs+e7azxGkJfmrAWUJeM42SdcHpODkVx70YTITHB5ZSZCHj1ecVU2p0ipKTcKwMhdR6cLMa4kE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699415274; c=relaxed/simple; bh=TNyuvqnv3Jz7TZWsgdOR43NBXKldvILAJpTAXStcz98=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=HZHx0OZ4RH8Elb3DRXG57QgM5J4OzsQBXal/NjzmV0e/d2gATSk9ME88eq3ljBDRycXFPof0vXEIFZsnIFOzK2YRJrK9Mb9OTxRe2oO3bO2zBmmkqUzwDDlzsHAVIDkY0cG3KK7NtnMUpswzzrGXIRi4pxZsJkYwAztyFE659RY= ARC-Authentication-Results: i=1; server2.sourceware.org X-QQ-mid: bizesmtp81t1699415261tymk60iu Received: from rios-cad121.hadoop.rioslab.org ( [58.60.1.9]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 08 Nov 2023 11:47:40 +0800 (CST) X-QQ-SSF: 01400000000000C0F000000A0000000 X-QQ-FEAT: YHTLUubWl25gNU2XX9WflV6xbh7T9lzf6Nzv5O8x1j6bUUsb6Z/KwvnZ4lpMw fs+hl9ecQnSn16gyB6St/p0kQR6DTX8y053nfQjeixmfXU0aiWe56v/wtC/BnDPZxAEk748 yKPboCJsrwnHVfioLkZeHMpeKI0u55GTnvwiXwZ7AgbmEEdPk0iK3VIooVeQIe8v+7JVnbB B2do6SXseM/5MfsABCkpCsnqdhaTcubeQjVldL2hah57hCFNWT14aUNbvMHf3ANr26bYa6f qD0q1u3VI9VlxisoOqbLbhvfnpbWXv8ddjkQJpwXEiTVcQbIqvndzv4Ye0qTmPk2Vq7WmNl J0EwC3rFqgqjtFqXkMWFmlk31UQ7Cn98Bp8H1SiBDpyp2lkqV4= X-QQ-GoodBg: 2 X-BIZMAIL-ID: 10959514183122626588 From: Lehua Ding To: gcc-patches@gcc.gnu.org Cc: vmakarov@redhat.com, richard.sandiford@arm.com, juzhe.zhong@rivai.ai, lehua.ding@rivai.ai Subject: [PATCH 0/7] ira/lra: Support subreg coalesce Date: Wed, 8 Nov 2023 11:47:33 +0800 Message-Id: <20231108034740.834590-1-lehua.ding@rivai.ai> X-Mailer: git-send-email 2.36.3 MIME-Version: 1.0 X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:rivai.ai:qybglogicsvrgz:qybglogicsvrgz6a-0 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, T_SPF_HELO_TEMPERROR, URIBL_SBL_A autolearn=no 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.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781966096955424851 X-GMAIL-MSGID: 1781966096955424851 Hi, These patchs try to support subreg coalesce feature in register allocation passes (ira and lra). Let's consider a RISC-V program (https://godbolt.org/z/ec51d91aT): ``` #include void foo (int32_t *in, int32_t *out, size_t m) { vint32m2_t result = __riscv_vle32_v_i32m2 (in, 32); vint32m1_t v0 = __riscv_vget_v_i32m2_i32m1 (result, 0); vint32m1_t v1 = __riscv_vget_v_i32m2_i32m1 (result, 1); for (size_t i = 0; i < m; i++) { v0 = __riscv_vadd_vv_i32m1(v0, v0, 4); v1 = __riscv_vmul_vv_i32m1(v1, v1, 4); } *(vint32m1_t*)(out+4*0) = v0; *(vint32m1_t*)(out+4*1) = v1; } ``` Before these patchs: ``` foo: li a5,32 vsetvli zero,a5,e32,m2,ta,ma vle32.v v4,0(a0) vmv1r.v v2,v4 vmv1r.v v1,v5 beq a2,zero,.L2 li a5,0 vsetivli zero,4,e32,m1,ta,ma .L3: addi a5,a5,1 vadd.vv v2,v2,v2 vmul.vv v1,v1,v1 bne a2,a5,.L3 .L2: vs1r.v v2,0(a1) addi a1,a1,16 vs1r.v v1,0(a1) ret ``` After these patchs: ``` foo: li a5,32 vsetvli zero,a5,e32,m2,ta,ma vle32.v v2,0(a0) beq a2,zero,.L2 li a5,0 vsetivli zero,4,e32,m1,ta,ma .L3: addi a5,a5,1 vadd.vv v2,v2,v2 vmul.vv v3,v3,v3 bne a2,a5,.L3 .L2: vs1r.v v2,0(a1) addi a1,a1,16 vs1r.v v3,0(a1) ret ``` As you can see, the two redundant vmv1r.v instructions were removed. The reason for the two redundant vmv1r.v instructions is because the current ira pass is being conservative in calculating the live range of pseduo registers that occupy multil hardregs. As in the following two RTL instructions. Where r134 occupies two physical registers and r135 and r136 occupy one physical register. At insn 12 point, ira considers the entire r134 pseudo register to be live, so r135 is in conflict with r134, as shown in the ira dump info. Then when the physical registers are allocated, r135 and r134 are allocated first because they are inside the loop body and have higher priority. This makes it difficult to assign r136 to overlap with r134, i.e., to assign r136 to hr100, thus eliminating the need for the vmv1r.v instruction. Thus two vmv1r.v instructions appear. If we refine the live information of r134 to the case of each subreg, we can remove this conflict. We can then create copies of the set with subreg reference, thus increasing the priority of the r134 allocation, which allow registers with bigger alignment requirements to prioritize the allocation of physical registers. In RVV, pseudo registers occupying two physical registers need to be time-2 aligned. ``` (insn 11 10 12 2 (set (reg/v:RVVM1SI 135 [ v0 ]) (subreg:RVVM1SI (reg/v:RVVM2SI 134 [ result ]) 0)) "/app/example.c":7:19 998 {*movrvvm1si_whole} (nil)) (insn 12 11 13 2 (set (reg/v:RVVM1SI 136 [ v1 ]) (subreg:RVVM1SI (reg/v:RVVM2SI 134 [ result ]) [16, 16])) "/app/example.c":8:19 998 {*movrvvm1si_whole} (expr_list:REG_DEAD (reg/v:RVVM2SI 134 [ result ]) (nil))) ``` ira dump: ;; a1(r136,l0) conflicts: a3(r135,l0) ;; total conflict hard regs: ;; conflict hard regs: ;; a3(r135,l0) conflicts: a1(r136,l0) a6(r134,l0) ;; total conflict hard regs: ;; conflict hard regs: ;; a6(r134,l0) conflicts: a3(r135,l0) ;; total conflict hard regs: ;; conflict hard regs: ;; ;; ... Popping a1(r135,l0) -- assign reg 97 Popping a3(r136,l0) -- assign reg 98 Popping a4(r137,l0) -- assign reg 15 Popping a5(r140,l0) -- assign reg 12 Popping a10(r145,l0) -- assign reg 12 Popping a2(r139,l0) -- assign reg 11 Popping a9(r144,l0) -- assign reg 11 Popping a0(r142,l0) -- assign reg 11 Popping a6(r134,l0) -- assign reg 100 Popping a7(r143,l0) -- assign reg 10 Popping a8(r141,l0) -- assign reg 15 The AArch64 SVE has the same problem. Consider the following code (https://godbolt.org/z/MYrK7Ghaj): ``` #include int bar (svbool_t pg, int64_t* base, int n, int64_t *in1, int64_t *in2, int64_t*out) { svint64x4_t result = svld4_s64 (pg, base); svint64_t v0 = svget4_s64(result, 0); svint64_t v1 = svget4_s64(result, 1); svint64_t v2 = svget4_s64(result, 2); svint64_t v3 = svget4_s64(result, 3); for (int i = 0; i < n; i += 1) { svint64_t v18 = svld1_s64(pg, in1); svint64_t v19 = svld1_s64(pg, in2); v0 = svmad_s64_z(pg, v0, v18, v19); v1 = svmad_s64_z(pg, v1, v18, v19); v2 = svmad_s64_z(pg, v2, v18, v19); v3 = svmad_s64_z(pg, v3, v18, v19); } svst1_s64(pg, out+0,v0); svst1_s64(pg, out+1,v1); svst1_s64(pg, out+2,v2); svst1_s64(pg, out+3,v3); } ``` Before these patchs: ``` bar: ld4d {z4.d - z7.d}, p0/z, [x0] mov z26.d, z4.d mov z27.d, z5.d mov z28.d, z6.d mov z29.d, z7.d cmp w1, 0 ... ``` After these patchs: ``` bar: ld4d {z28.d - z31.d}, p0/z, [x0] cmp w1, 0 ... ``` Lehua Ding (7): ira: Refactor the handling of register conflicts to make it more general ira: Add live_subreg problem and apply to ira pass ira: Support subreg live range track ira: Support subreg copy ira: Add all nregs >= 2 pseudos to tracke subreg list lra: Apply live_subreg df_problem to lra pass lra: Support subreg live range track and conflict detect gcc/Makefile.in | 1 + gcc/df-problems.cc | 889 ++++++++++++++++++++++++++++++++++++++- gcc/df.h | 93 +++- gcc/hard-reg-set.h | 33 ++ gcc/ira-build.cc | 458 ++++++++++++++++---- gcc/ira-color.cc | 851 ++++++++++++++++++++++++++----------- gcc/ira-conflicts.cc | 221 +++++++--- gcc/ira-emit.cc | 24 +- gcc/ira-int.h | 67 ++- gcc/ira-lives.cc | 527 +++++++++++++++++------ gcc/ira.cc | 77 ++-- gcc/lra-assigns.cc | 111 ++++- gcc/lra-coalesce.cc | 20 +- gcc/lra-constraints.cc | 111 +++-- gcc/lra-int.h | 33 ++ gcc/lra-lives.cc | 661 ++++++++++++++++++++++++----- gcc/lra-remat.cc | 13 +- gcc/lra-spills.cc | 22 +- gcc/lra.cc | 139 +++++- gcc/reginfo.cc | 14 + gcc/rtl.h | 14 + gcc/subreg-live-range.cc | 649 ++++++++++++++++++++++++++++ gcc/subreg-live-range.h | 343 +++++++++++++++ gcc/timevar.def | 1 + 24 files changed, 4564 insertions(+), 808 deletions(-) create mode 100644 gcc/subreg-live-range.cc create mode 100644 gcc/subreg-live-range.h