From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 6DC203858408; Tue, 28 Sep 2021 12:38:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6DC203858408 Received: from relay1.suse.de (relay1.suse.de [149.44.160.133]) by smtp-out1.suse.de (Postfix) with ESMTP id 277C52235B; Tue, 28 Sep 2021 12:38:09 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay1.suse.de (Postfix) with ESMTPS id 0B1A025D44; Tue, 28 Sep 2021 12:38:09 +0000 (UTC) Date: Tue, 28 Sep 2021 14:38:08 +0200 (CEST) From: Richard Biener To: Ilya Leoshkevich cc: gcc-patches@gcc.gnu.org, Andreas Krebbel Subject: Re: [PATCH v3 3/3] reassoc: Test rank biasing In-Reply-To: <031412fdd4dce6be1123952b508425367cac84c9.camel@linux.ibm.com> Message-ID: <7qr397qs-4r5-1o53-3r4-79796pn4prs7@fhfr.qr> References: <20210926110936.344019-1-iii@linux.ibm.com> <20210926110936.344019-4-iii@linux.ibm.com> <031412fdd4dce6be1123952b508425367cac84c9.camel@linux.ibm.com> MIME-Version: 1.0 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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, 28 Sep 2021 12:38:11 -0000 On Tue, 28 Sep 2021, Ilya Leoshkevich wrote: > On Tue, 2021-09-28 at 13:28 +0200, Richard Biener wrote: > > On Sun, 26 Sep 2021, Ilya Leoshkevich wrote: > > > > > Add both positive and negative tests. > > > > The tests will likely be quite fragile with respect to what is > > actually vectorized on which target.  If you move the tests > > to gcc.dg/vect/ you could at least do > > > > /* { dg-require-effective-target vect_int } */ > > > > do you need to look for the exact GIMPLE IL or is it enough to > > verify we are vectorizing the reduction? > > Actually I don't think vectorization is that important here, and I > only check how many times sum_x = sum_y + _z appears. So I use > (?:vect_)?, which may or may not be there. > > An alternative I considered was to use -fno-tree-vectorize to get > smaller regexes, but I thought it would be nice to know that > vectorization does not mess up reassociation results. Ah, OK. So lets go ahead with the patch unchanged, but be prepared to deal with eventual fallout here on weird targets. Thanks, Richard.