From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 7A7BD3858D32 for ; Mon, 12 Jun 2023 19:02:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A7BD3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0F68A1FB; Mon, 12 Jun 2023 12:02:50 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD0373F587; Mon, 12 Jun 2023 12:02:03 -0700 (PDT) From: Richard Sandiford To: Jeff Law via Gcc-patches Mail-Followup-To: Jeff Law via Gcc-patches ,juzhe.zhong@rivai.ai, Jeff Law , kito.cheng@gmail.com, kito.cheng@sifive.com, palmer@dabbelt.com, palmer@rivosinc.com, rdapp.gcc@gmail.com, pan2.li@intel.com, richard.sandiford@arm.com Cc: juzhe.zhong@rivai.ai, Jeff Law , kito.cheng@gmail.com, kito.cheng@sifive.com, palmer@dabbelt.com, palmer@rivosinc.com, rdapp.gcc@gmail.com, pan2.li@intel.com Subject: Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS References: <20230609104105.9100-1-juzhe.zhong@rivai.ai> Date: Mon, 12 Jun 2023 20:02:02 +0100 In-Reply-To: (Jeff Law via Gcc-patches's message of "Fri, 9 Jun 2023 08:33:30 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-21.8 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Jeff Law via Gcc-patches writes: > On 6/9/23 04:41, juzhe.zhong@rivai.ai wrote: >> @@ -4342,135 +4510,81 @@ pass_vsetvl::cleanup_insns (void) const >> } >> } >> >> +/* Return true if the SET result is not used by any instructions. */ >> +static bool >> +has_no_uses (basic_block cfg_bb, rtx_insn *rinsn, int regno) >> +{ >> + /* Handle the following case that can not be detected in RTL_SSA. */ >> + /* E.g. >> + li a5, 100 >> + vsetvli a6, a5... >> + ... >> + vadd (use a6) >> + >> + The use of "a6" is removed from "vadd" but the information is >> + not updated in RTL_SSA framework. We don't want to re-new >> + a new RTL_SSA which is expensive, instead, we use data-flow >> + analysis to check whether "a6" has no uses. */ > I'm a bit surprised there wasn't a reasonable way to update the RTL SSA > framework for this case. If we were to remove the entire vadd, then we > would have to update the uses of a6. If we have that capability, then I > would expect we could refactor the updating code so that we had an API > to remove an operand from an instruction. > > In fact, if we have a constant propagator in the RTL SSA framework, > wouldn't it have to have this capability? RTL-SSA isn't supposed to be feature-complete in its current state. So yeah, if something is missing, it's better to add it to RTL-SSA rather than work around it in consumers. (Responding without fully understanding the context though, sorry.) Thanks, Richard