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 D23763858412 for ; Fri, 19 May 2023 11:07:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D23763858412 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 6104A1FB; Fri, 19 May 2023 04:08:17 -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 E78013F762; Fri, 19 May 2023 04:07:31 -0700 (PDT) From: Richard Sandiford To: "juzhe.zhong\@rivai.ai" Mail-Followup-To: "juzhe.zhong\@rivai.ai" ,gcc-patches , rguenther , richard.sandiford@arm.com Cc: gcc-patches , rguenther Subject: Re: [PATCH V11] VECT: Add decrement IV support in Loop Vectorizer References: <20230516102319.163752-1-juzhe.zhong@rivai.ai> Date: Fri, 19 May 2023 12:07:30 +0100 In-Reply-To: (juzhe's message of "Fri, 19 May 2023 18:56:44 +0800") 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=-22.9 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: "juzhe.zhong@rivai.ai" writes: > Hi, Richard. Thanks for the comments. > > Would you mind telling me whether it is possible that we can make decrement IV support into GCC middle-end ? > > If yes, could you tell what I should do next for the patches since I am confused that it seems the implementation of this > patch should totally be abandoned and need to rewrite the whole thing. No, I haven't said that. Like I say, I haven't had time to review the decrementing IV part of the patch yet. But the change I mentioned earlier seemed like an unrelated fix that should go in first. I was hoping to partially unblock your work by reviewing that part in isolation rather than waiting until I had time to review the whole patch. But I guess that's just created confusion rather than been helpful, sorry. In other words: the decrementing IV patch should (I hope) be an optimisation. It shouldn't be needed for correctness. The current incrementing IVs should work for LOAD_LEN, but perhaps inefficiently. Is that right? In contrast, the change to vect_get_loop_len is a correctness fix and I can't see how RVV would work without it. Thanks, Richard