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 767C8385742D for ; Wed, 1 Sep 2021 09:59:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 767C8385742D 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 0F67B1042; Wed, 1 Sep 2021 02:59:42 -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 74A0B3F766; Wed, 1 Sep 2021 02:59:41 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener , Richard Biener , GCC Patches , richard.sandiford@arm.com Cc: Richard Biener , GCC Patches Subject: Re: [PATCH] tree-optimization/102139 - fix SLP DR base alignment References: Date: Wed, 01 Sep 2021 10:59:40 +0100 In-Reply-To: (Richard Biener's message of "Tue, 31 Aug 2021 13:43:07 +0200") 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.3 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: Wed, 01 Sep 2021 09:59:43 -0000 Richard Biener writes: > On Tue, Aug 31, 2021 at 11:26 AM Richard Biener via Gcc-patches > wrote: >> >> When doing whole-function SLP we have to make sure the recorded >> base alignments we compute as the maximum alignment seen for a >> base anywhere in the function is actually valid at the point >> we want to make use of it. Ah, yeah, the danger of optimisations that silently rely on the then-current restrictions :-( >> To make this work we now record the stmt the alignment was derived >> from in addition to the DRs innermost behavior and we use a >> dominance check to verify the recorded info is valid when doing >> BB vectorization. >> >> Note this leaves a small(?) hole for the case where we have sth >> like >> >> unaligned DR >> call (); // does not return >> aligned DR >> >> since we'll derive an aligned access for the earlier DR but the >> later DR is never actually reached since the call does not >> return. To plug this hole one option (for the easy backporting) >> would be to simply not use the base-alignment recording at all. >> Alternatively we'd have to store the dataref grouping 'id' somewhere >> in the DR itself and use that to handle this particular case. > > It turns out this isn't too difficult so the following is a patch adjusted > to cover that case together with a testcase. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > OK? TBH I know nothing about this group id scheme, so I'm not really in a position to comment. But it LGTM from the (few) bits I do understand. I guess we're leaving the same easter egg for loop optimisation if we ever support early exits, but I'm not sure what to do about that. Thanks, Richard > > Thanks, > Richard. > > 2021-08-31 Richard Biener > > PR tree-optimization/102139 > * tree-vectorizer.h (vec_base_alignments): Adjust hash-map > type to record a std::pair of the stmt-info and the innermost > loop behavior. > (dr_vec_info::group): New member. > * tree-vect-data-refs.c (vect_record_base_alignment): Adjust. > (vect_compute_data_ref_alignment): Verify the recorded > base alignment can be used. > (data_ref_pair): Remove. > (dr_group_sort_cmp): Adjust. > (vect_analyze_data_ref_accesses): Store the group-ID in the > dr_vec_info and operate on a vector of dr_vec_infos. > > * gcc.dg/torture/pr102139.c: New testcase.