From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93174 invoked by alias); 21 Nov 2017 16:44:05 -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 93146 invoked by uid 89); 21 Nov 2017 16:44:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,GIT_PATCH_2,KAM_NUMSUBJECT,KB_WAM_FROM_NAME_SINGLEWORD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1010, H*F:D*be, HDKIM-Filter:v2.9.2 X-HELO: smtp3.sgsi.ucl.ac.be Received: from smtp.sgsi.ucl.ac.be (HELO smtp3.sgsi.ucl.ac.be) (130.104.5.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Nov 2017 16:44:02 +0000 Received: from localhost (wifi-secure2-454.sri.ucl.ac.be [130.104.97.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: verhetsel@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 88DAF67DB0C; Tue, 21 Nov 2017 17:43:52 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 88DAF67DB0C References: <87d14brhj6.fsf@uclouvain.be> User-agent: mu4e 0.9.18; emacs 25.3.1 From: Kilian Verhetsel To: Richard Biener Cc: alan.hayward@arm.com, GCC Patches Subject: Re: [PATCH] Fix result for conditional reductions matching at index 0 In-reply-to: Date: Tue, 21 Nov 2017 16:49:00 -0000 Message-ID: <87zi7fbn07.fsf@uclouvain.be> MIME-Version: 1.0 Content-Type: text/plain X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 88DAF67DB0C.A5D80 X-SGSI-MailScanner: Found to be clean X-SGSI-From: kilian.verhetsel@uclouvain.be X-SGSI-Spam-Status: No X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg01919.txt.bz2 > This is PR81179 I think, please mention that in the changelog. Correct, my bad for missing that. > This unconditionally pessimizes code even if there is no valid index > zero, right? Almost, since for a loop such as: #define OFFSET 1 unsigned int find(const unsigned int *a, unsigned int v) { unsigned int result = 120; for (unsigned int i = OFFSET; i < 32+OFFSET; i++) { if (a[i-OFFSET] == v) result = i; } return result; } the index i will match the contents of the index vector used here --- but this does indeed pessimize the code generated for, say, OFFSET = 2. It is probably more sensible to use the existing code path in those situations. > The issue with the COND_REDUCITION index vector is overflow IIRC. Does that mean such overflows can already manifest themselves for regular COND_REDUCTION? I had assumed sufficient checks were already in place because of the presence of the is_nonwrapping_integer_induction test.