From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111855 invoked by alias); 25 Oct 2019 16:18:07 -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 111847 invoked by uid 89); 25 Oct 2019 16:18:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:nycvar., H*i:sk:nycvar., H*MI:sk:nycvar., responses 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, 25 Oct 2019 16:18:05 +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 34DB6328; Fri, 25 Oct 2019 09:18:04 -0700 (PDT) Received: from [10.2.206.37] (e107157-lin.cambridge.arm.com [10.2.206.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D2E6A3F71A; Fri, 25 Oct 2019 09:18:03 -0700 (PDT) Subject: Re: [PATCH 1/2][vect]PR 88915: Vectorize epilogues when versioning loops To: Richard Biener Cc: gcc-patches References: <385547e6-abbd-3633-ad69-d4fb6e604c97@arm.com> <7a523cc4-d43f-fa56-f190-9a5c18488b42@arm.com> <97dbaa36-107b-e078-05a5-0e8dc3700e9a@arm.com> From: "Andre Vieira (lists)" Message-ID: <6759f6dd-7b09-b455-fb06-c41eb6f7ae02@arm.com> Date: Fri, 25 Oct 2019 16:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg01852.txt.bz2 On 22/10/2019 14:56, Richard Biener wrote: > On Tue, 22 Oct 2019, Andre Vieira (lists) wrote: > >> Hi Richi, >> >> See inline responses to your comments. >> >> On 11/10/2019 13:57, Richard Biener wrote: >>> On Thu, 10 Oct 2019, Andre Vieira (lists) wrote: >>> >>>> Hi, >>>> >> >>> >>> + >>> + /* Keep track of vector sizes we know we can vectorize the epilogue >>> with. */ >>> + vector_sizes epilogue_vsizes; >>> }; >>> >>> please don't enlarge struct loop, instead track this somewhere >>> in the vectorizer (in loop_vinfo? I see you already have >>> epilogue_vinfos there - so the loop_vinfo simply lacks >>> convenient access to the vector_size?) I don't see any >>> use that could be trivially adjusted to look at a loop_vinfo >>> member instead. >> >> Done. >>> >>> For the vect_update_inits_of_drs this means that we'd possibly >>> do less CSE. Not sure if really an issue. >> >> CSE of what exactly? You are afraid we are repeating a calculation here we >> have done elsewhere before? > > All uses of those inits now possibly get the expression instead of > just the SSA name we inserted code for once. But as said, we'll see. > This code changed after some comments from Richard Sandiford. > + /* We are done vectorizing the main loop, so now we update the > epilogues > + stmt_vec_info's. At the same time we set the gimple UID of each > + statement in the epilogue, as these are used to look them up in the > + epilogues loop_vec_info later. We also keep track of what > + stmt_vec_info's have PATTERN_DEF_SEQ's and RELATED_STMT's that might > + need updating and we construct a mapping between variables defined > in > + the main loop and their corresponding names in epilogue. */ > + for (unsigned i = 0; i < epilogue->num_nodes; ++i) > > so for the following code I wonder if you can make use of the > fact that loop copying also copies UIDs, so you should be able > to match stmts via their UIDs and get at the other loop infos > stmt_info by the copy loop stmt UID. > > I wonder why you need no modification for the SLP tree? > I checked with Tamar and the SLP tree works with the position of operands and not SSA_NAMES. So we should be fine.