From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id 24A64385840F for ; Sun, 31 Dec 2023 17:54:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 24A64385840F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 24A64385840F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::230 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704045271; cv=none; b=r3+ohv/LxrVkLyL5/0zoxCm4G3GtSVUIpykxdsJST+Yjh7SLZP5dYjPaHJ9gCk3CCwRTFSfHlHtLNE71AbgKiQGCk4+m3Pd7LN/WiHp9W+ZhNxEWtN2yQ9uETdv//7zWCgR8Cusbk6b4YoxywFtYijtxd9f9jRcNmgtYek3gg6I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704045271; c=relaxed/simple; bh=1asISdWEK0n/01OFiG3uxVMQP/W+b4aXHTYU1E6hRI0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=cmGLVIlpfJ1AFySOkTEKDZ22KyEnacOfovUbATjAfVOBCrDFqwrXvM3NI+dFcIYRm8wMOE10yFQh/4YFW31q7zKHRMzM7DRKW3l9oWEyQ1AXydDjpXlVD/Bzq7DRKcT9v7XZOwBEn7lQLRfN2y0eMYFeWz8Cg7+f4m2HJNoN0vM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oi1-x230.google.com with SMTP id 5614622812f47-3bb53e20a43so6951620b6e.1 for ; Sun, 31 Dec 2023 09:54:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704045264; x=1704650064; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6a4Z0NXfpFGGCnsyBGw8LhaHq1MDjxQmBCcd8ph1CPM=; b=OvjRZKbDSOUjdzI/jnrsDd0mLwqrO8VJKmt/UwkInWRM7zVBt1w3PS1/6n1zziNFvB +CPLhvAUojMBpV9AjNxGZ+F3RyHqAOtCYyr1/H9ioTTP86mx7LaibDjsHD0xCiy7cld+ b/OEjIA4WvodG+8f/YptY2zoId4ikuTEgPAQnlqGBqag9FqbGgoyOMbyY7HQFVIkXC34 SSR/DxszZr9lQpOdcJfCaVhaThalEt6WXLUtCHlVfAT95GCqMURdL4Hbdlxbqod7f+fi slKKKThhh9rzWQRZk1xiSEn/a19Fh8uoxibfSIWDEet68cxsCZL6lON9rKIj16eZ3LVM nJ5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704045264; x=1704650064; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6a4Z0NXfpFGGCnsyBGw8LhaHq1MDjxQmBCcd8ph1CPM=; b=XVRzL0U0oKqFr6TjuSubBUMVxLiOmfO/NcuPyNl0I+tPN0sZ2XCSke+kNiZHNGUOir 3ArAfgP5hDp0Vsej/+8UxbrWLK7jSZcOu0mMWe5NaK3zfmmvXgD1j7n6wwGS69G4dbEG isLh75j3b8yWWquShXNaK2JIZQOq4cqVM7iSiD4O+1QDkmzSHDX3GlTT3Pzf/PP4Mjyj OW06GLMaTGDonvpIejxrT8teXtjHz+V3y0L+1arOVvfAf/wVV4KDoUgkdwhqXlKSRweU vUx6FtrnJaUzjifcIW2EIwxd96p/E3Pi7izFU3D3HMpUw4VqlQl8j/wYej6uruGf+Qa2 dyfg== X-Gm-Message-State: AOJu0YxltHOE6N//tKU7ooj//DfhLurDAV4zFrAiBFSPYWcyEwVqQ1oh jyVzKslNmtw+0ZW1mdYzpY2yD4TdsDY= X-Google-Smtp-Source: AGHT+IE00jD9kIpQqWK2hZLFj/wGr84B8RRKSeTnSse+ng8jsrT1+BJIihy/dRiVBMQkxkEPR0NRWQ== X-Received: by 2002:a05:6808:2388:b0:3bb:f6a0:f34a with SMTP id bp8-20020a056808238800b003bbf6a0f34amr2510109oib.31.1704045264549; Sun, 31 Dec 2023 09:54:24 -0800 (PST) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id g10-20020a056a000b8a00b006d9b30b33b0sm12797137pfj.196.2023.12.31.09.54.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 Dec 2023 09:54:24 -0800 (PST) Message-ID: <9ea27a43-ae49-4a87-992d-9ea553628fd0@gmail.com> Date: Sun, 31 Dec 2023 10:54:16 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] RISC-V: Count pointer type SSA into RVV regs liveness for dynamic LMUL cost model Content-Language: en-US To: Juzhe-Zhong , gcc-patches@gcc.gnu.org Cc: kito.cheng@gmail.com, kito.cheng@sifive.com, rdapp.gcc@gmail.com References: <20231229012102.2424314-1-juzhe.zhong@rivai.ai> From: Jeff Law In-Reply-To: <20231229012102.2424314-1-juzhe.zhong@rivai.ai> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,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 List-Id: On 12/28/23 18:21, Juzhe-Zhong wrote: > This patch fixes the following choosing unexpected big LMUL which cause register spillings. > > Before this patch, choosing LMUL = 4: > > addi sp,sp,-160 > addiw t1,a2,-1 > li a5,7 > bleu t1,a5,.L16 > vsetivli zero,8,e64,m4,ta,ma > vmv.v.x v4,a0 > vs4r.v v4,0(sp) ---> spill to the stack. > vmv.v.x v4,a1 > addi a5,sp,64 > vs4r.v v4,0(a5) ---> spill to the stack. > > The root cause is the following codes: > > if (poly_int_tree_p (var) > || (is_gimple_val (var) > && !POINTER_TYPE_P (TREE_TYPE (var)))) > > We count the variable as consuming a RVV reg group when it is not POINTER_TYPE. > > It is right for load/store STMT for example: > > _1 = (MEM)*addr --> addr won't be allocated an RVV vector group. > > However, we find it is not right for non-load/store STMT: > > _3 = _1 == x_8(D); > > _1 is pointer type too but we does allocate a RVV register group for it. > > So after this patch, we are choosing the perfect LMUL for the testcase in this patch: > > ble a2,zero,.L17 > addiw a7,a2,-1 > li a5,3 > bleu a7,a5,.L15 > srliw a5,a7,2 > slli a6,a5,1 > add a6,a6,a5 > lui a5,%hi(replacements) > addi t1,a5,%lo(replacements) > slli a6,a6,5 > lui t4,%hi(.LANCHOR0) > lui t3,%hi(.LANCHOR0+8) > lui a3,%hi(.LANCHOR0+16) > lui a4,%hi(.LC1) > vsetivli zero,4,e16,mf2,ta,ma > addi t4,t4,%lo(.LANCHOR0) > addi t3,t3,%lo(.LANCHOR0+8) > addi a3,a3,%lo(.LANCHOR0+16) > addi a4,a4,%lo(.LC1) > add a6,t1,a6 > addi a5,a5,%lo(replacements) > vle16.v v18,0(t4) > vle16.v v17,0(t3) > vle16.v v16,0(a3) > vmsgeu.vi v25,v18,4 > vadd.vi v24,v18,-4 > vmsgeu.vi v23,v17,4 > vadd.vi v22,v17,-4 > vlm.v v21,0(a4) > vmsgeu.vi v20,v16,4 > vadd.vi v19,v16,-4 > vsetvli zero,zero,e64,m2,ta,mu > vmv.v.x v12,a0 > vmv.v.x v14,a1 > .L4: > vlseg3e64.v v6,(a5) > vmseq.vv v2,v6,v12 > vmseq.vv v0,v8,v12 > vmsne.vv v1,v8,v12 > vmand.mm v1,v1,v2 > vmerge.vvm v2,v8,v14,v0 > vmv1r.v v0,v1 > addi a4,a5,24 > vmerge.vvm v6,v6,v14,v0 > vmerge.vim v2,v2,0,v0 > vrgatherei16.vv v4,v6,v18 > vmv1r.v v0,v25 > vrgatherei16.vv v4,v2,v24,v0.t > vs1r.v v4,0(a5) > addi a3,a5,48 > vmv1r.v v0,v21 > vmv2r.v v4,v2 > vcompress.vm v4,v6,v0 > vs1r.v v4,0(a4) > vmv1r.v v0,v23 > addi a4,a5,72 > vrgatherei16.vv v4,v6,v17 > vrgatherei16.vv v4,v2,v22,v0.t > vs1r.v v4,0(a3) > vmv1r.v v0,v20 > vrgatherei16.vv v4,v6,v16 > addi a5,a5,96 > vrgatherei16.vv v4,v2,v19,v0.t > vs1r.v v4,0(a4) > bne a6,a5,.L4 > > No spillings, no "sp" register used. > > Tested on both RV32 and RV64, no regression. > > Ok for trunk ? > > PR target/113112 > > gcc/ChangeLog: > > * config/riscv/riscv-vector-costs.cc (compute_nregs_for_mode): Fix pointer type liveness count. > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/costmodel/riscv/rvv/pr113112-4.c: New test. > > --- > gcc/config/riscv/riscv-vector-costs.cc | 12 ++++++-- > .../vect/costmodel/riscv/rvv/pr113112-4.c | 28 +++++++++++++++++++ > 2 files changed, 37 insertions(+), 3 deletions(-) > create mode 100644 gcc/testsuite/gcc.dg/vect/costmodel/riscv/rvv/pr113112-4.c > > diff --git a/gcc/config/riscv/riscv-vector-costs.cc b/gcc/config/riscv/riscv-vector-costs.cc > index 0c485dc4f29..b41a79429d4 100644 > --- a/gcc/config/riscv/riscv-vector-costs.cc > +++ b/gcc/config/riscv/riscv-vector-costs.cc > @@ -277,9 +277,12 @@ compute_local_live_ranges ( > { > unsigned int point = program_point.point; > gimple *stmt = program_point.stmt; > + stmt_vec_info stmt_info = program_point.stmt_info; > tree lhs = gimple_get_lhs (stmt); > if (lhs != NULL_TREE && is_gimple_reg (lhs) > - && !POINTER_TYPE_P (TREE_TYPE (lhs))) > + && (!POINTER_TYPE_P (TREE_TYPE (lhs)) > + || STMT_VINFO_TYPE (vect_stmt_to_vectorize (stmt_info)) > + != store_vec_info_type)) > { > biggest_mode = get_biggest_mode (biggest_mode, > TYPE_MODE (TREE_TYPE (lhs))); > @@ -305,7 +308,10 @@ compute_local_live_ranges ( > the future. */ > if (poly_int_tree_p (var) > || (is_gimple_val (var) > - && !POINTER_TYPE_P (TREE_TYPE (var)))) > + && (!POINTER_TYPE_P (TREE_TYPE (var)) > + || STMT_VINFO_TYPE ( > + vect_stmt_to_vectorize (stmt_info)) > + != load_vec_info_type))) > { > biggest_mode > = get_biggest_mode (biggest_mode, Just a nit. Why not compute vect_stmt_to_vectorize (stmt_info) into a local to improve the bad line break? Or perhaps even compute STMT_VINFO_TYPE (...) into a local? OK with or without a change for that nit. jeff