From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58659 invoked by alias); 15 Nov 2019 11:33:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 58650 invoked by uid 89); 15 Nov 2019 11:33:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:nxkJ7C3, H*f:GcBa, H*f:sk:nxkJ7C3, H*i:GcBa X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Nov 2019 11:33:18 +0000 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 D4FA931B; Fri, 15 Nov 2019 03:33:15 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 60A103F6C4; Fri, 15 Nov 2019 03:33:15 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,GCC Patches , richard.sandiford@arm.com Cc: GCC Patches Subject: Re: [3/8] Add flags to dr_with_seg_len_pair_t References: Date: Fri, 15 Nov 2019 11:37:00 -0000 In-Reply-To: (Richard Biener's message of "Fri, 15 Nov 2019 12:06:25 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg01373.txt.bz2 Richard Biener writes: > On Mon, Nov 11, 2019 at 7:47 PM Richard Sandiford > wrote: >> >> This patch adds a bunch of flags to dr_with_seg_len_pair_t, >> for use by later patches. The update to tree-loop-distribution.c >> is conservatively correct, but might be tweakable later. > > Does this all work with interleaved SLP loads/stores like > > a[i] = b[i]; > tem1 = b[i+1]; > tem2 = b[i+2]; > a[i+2] = tem2; > a[i+1] = tem1; > > where we don't preserve the scalar order but emit code at the > latest stmt of the grouped access? Yeah. vect-alias-check-9.c is a less sophisticated example of that. In both cases vect_preserves_scalar_order_p is false. > That is, what does "preserve scalar oder" actually mean? It's supposed to mean that if a memory access A from the first group and a memory access B from the second group occur within the same scalar iteration, the order of the accesses in the vector loop body will be the same as it was in the scalar loop body. In other words, the order of the vector stmts honours any dependencies between the accesses that occur within one iteration of the scalar loop. Thanks, Richard