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 285363858D28 for ; Tue, 14 Dec 2021 11:47:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 285363858D28 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 CA83E6D; Tue, 14 Dec 2021 03:47:32 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 37E253F5A1; Tue, 14 Dec 2021 03:47:32 -0800 (PST) From: Richard Sandiford To: Robin Dapp Mail-Followup-To: Robin Dapp , "Kewen.Lin" , GCC Patches , richard.sandiford@arm.com Cc: "Kewen.Lin" , GCC Patches Subject: Re: [PATCH] vect: Add bias parameter for partial vectorization References: <440687a0-d6e5-50e0-7105-7914b910c8c6@linux.ibm.com> <3977d753-2bb4-3c47-22d2-b4948ddc38bd@linux.ibm.com> Date: Tue, 14 Dec 2021 11:47:30 +0000 In-Reply-To: (Robin Dapp's message of "Mon, 13 Dec 2021 19:51:12 +0100") 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=-6.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 11:47:35 -0000 Robin Dapp writes: > Hi Richard, > > I incorporated all your remarks (sorry for the hunk from a different > branch) except for this one: > >> Think it would be better to make it: >> >> if (use_bias_adjusted_len) >> { >> gcc_assert (i == 0); >> >> But do we need to do this? Code should only care about the final value, >> so I didn't think we would need to keep the intermediate unbiased length >> alongside the biased one. (Or maybe we do. My memory is a bit rusty, >> sorry.) > > I'd agree that we generally don't need to keep the unbiased length. > However "loop_len" being a phi node, I wasn't sure how or where to > properly apply the bias (except via creating a new variable like I did). > Would be thankful about a pointer here. Ah, I see. Yeah, I guess the loop manip stuff does still need access to the unbiased value, so I agree we should keep both. Thanks, Richard