From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17052 invoked by alias); 22 Nov 2017 09:14:11 -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 14784 invoked by uid 89); 22 Nov 2017 09:14:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,GIT_PATCH_2,KAM_NUMSUBJECT,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=him X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Nov 2017 09:14:07 +0000 Received: by mail-wm0-f46.google.com with SMTP id l188so6961181wma.1 for ; Wed, 22 Nov 2017 01:14:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K1aGPOUSh7tddavER18xbXdaW7TPk3VKud7+I279vCQ=; b=o8Ol9VqQGhl+BasD8NXqt6jzXNzLyUw2EmcszRfs3gk5Bb3ClYRWVYHvQUoSHZIUOr wBwc4wu8HCkuUIdw+4bW+TbKMOWrV1OkufNNZ0LxUcZDB+VTL6tmK5BHtNQLwusjPyQP 2UKvjwD99OL74H2oWfLvX1iTRSo/j3/GW2V4kdXoAWwW1zRUJqgkSq0/t3xtSluVTV1c hbLF+7w8VW/lQy7M2kG5ZFL/UnW9s61/+eY2z+L97gr/QhXpgEVcA00I3x+rksYf7zHO rwAj8oTmW9qrqR1BbnzoOyNlGR5/ka8mGpQC/jmId+mode2hJ3Xr18k2TbJ2KTmtEJXd KuHw== X-Gm-Message-State: AJaThX4Iu50i2Cw2+yVsqK15E4RXxYnjbLIV0FQlJ2bkccqS+xRRZiGd CvG4UVfqS+xjWgrFZ22JpD/FASewobkZ6jibwWA= X-Google-Smtp-Source: AGs4zMZv9cAVL1QpghKKqZtQ82dQ0Wzgwrro+A5krwZCqto61R2NxZH1Zzg0ZxC0aLe9XX74V1+nGJYAbM+b8wmQGoA= X-Received: by 10.80.208.195 with SMTP id g3mr28471633edf.246.1511342044934; Wed, 22 Nov 2017 01:14:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.143.34 with HTTP; Wed, 22 Nov 2017 01:14:04 -0800 (PST) In-Reply-To: <87zi7fbn07.fsf@uclouvain.be> References: <87d14brhj6.fsf@uclouvain.be> <87zi7fbn07.fsf@uclouvain.be> From: Richard Biener Date: Wed, 22 Nov 2017 09:17:00 -0000 Message-ID: Subject: Re: [PATCH] Fix result for conditional reductions matching at index 0 To: Kilian Verhetsel Cc: alan.hayward@arm.com, GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg01980.txt.bz2 On Tue, Nov 21, 2017 at 5:43 PM, Kilian Verhetsel wrote: > >> 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. But only if we need the index vector? The patch looked like you're changing how other modes are handled (in my look I didn't make myself familiar with the various modes again...). Anyway, Alan hopefully remembers what he coded so I'll defer to him here. If Alan is happy with the patch consider it approved. Thanks, Richard.