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 9857E385DC14 for ; Tue, 26 May 2020 12:49:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9857E385DC14 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@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 4BFA330E; Tue, 26 May 2020 05:49:06 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3F7663F6C4; Tue, 26 May 2020 05:49:05 -0700 (PDT) From: Richard Sandiford To: "Kewen.Lin" Mail-Followup-To: "Kewen.Lin" , GCC Patches , Richard Guenther , Bill Schmidt , dje.gcc@gmail.com, Segher Boessenkool , richard.sandiford@arm.com Cc: GCC Patches , Richard Guenther , Bill Schmidt , dje.gcc@gmail.com, Segher Boessenkool Subject: Re: [PATCH 5/7] vect: Support vector load/store with length in vectorizer References: <30906c0d-3b9f-e1e6-156f-c01fcf229cb9@linux.ibm.com> <4b7f2daf-467e-d940-b79c-31c1c30a1dd4@linux.ibm.com> Date: Tue, 26 May 2020 13:49:03 +0100 In-Reply-To: <4b7f2daf-467e-d940-b79c-31c1c30a1dd4@linux.ibm.com> (Kewen Lin's message of "Tue, 26 May 2020 13:57:00 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 26 May 2020 12:49:08 -0000 "Kewen.Lin" writes: > @@ -626,6 +645,12 @@ public: > /* True if have decided to use a fully-masked loop. */ > bool fully_masked_p; > > + /* Records whether we still have the option of using a length access loop. */ > + bool can_with_length_p; > + > + /* True if have decided to use length access for the loop fully. */ > + bool fully_with_length_p; Rather than duplicate the flags like this, I think we should have three bits of information: (1) Can the loop operate on partial vectors? Starts off optimistically assuming "yes", gets set to "no" when we find a counter-example. (2) If we do decide to use partial vectors, will we need loop masks? (3) If we do decide to use partial vectors, will we need lengths? Vectorisation using partial vectors succeeds if (1) && ((2) != (3)) LOOP_VINFO_CAN_FULLY_MASK_P currently tracks (1) and LOOP_VINFO_MASKS currently tracks (2). In pathological cases it's already possible to have (1) && !(2), see r9-6240 for an example. With the new support, LOOP_VINFO_LENS tracks (3). So I don't think we need the can_with_length_p. What is now LOOP_VINFO_CAN_FULLY_MASK_P can continue to track (1) for both approaches, with the final choice of approach only being made at the end. Maybe it would be worth renaming it to something more generic though, now that we have two approaches to partial vectorisation. I think we can assume for now that no arch will be asymmetrical, and require (say) loop masks for loads and lengths for stores. So if that does happen (i.e. if (2) && (3) ends up being true) we should just be able to punt on partial vectorisation. Some of the new length code looks like it's copied and adjusted from the corresponding mask code. It would be good to share the code instead where possible, e.g. when deciding whether an IV can overflow. Thanks, Richard