From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81224 invoked by alias); 17 Mar 2018 12:48:22 -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 81104 invoked by uid 89); 17 Mar 2018 12:48:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-14.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 17 Mar 2018 12:48:03 +0000 Received: by mail-wm0-f42.google.com with SMTP id t6so7674556wmt.5 for ; Sat, 17 Mar 2018 05:48:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=/Kl4JT+iFgR0E6N7yHiAmIPKiEZc/BCRQt7uYtGwl3o=; b=MdwzqWyMFhfQA7hC4mRDVoCXxElHgbHMfxJC8L5ertJAojBJvm/uVYQldZW8UeTsA4 xUBsh7JXEYYxRrpPyyGQ2TFkd2183eN1EX5DAIz9VYbWYlOfvLU4esLv1XkC1W6A94h8 0/QpnfX5c/5vqn/ypFZqycx8W1OAimdNBk9oVFIiT1mI4txIhV61joGJkd9EBAwW1ADd 2XcSiXGjTatzFc8lclCO8yyd8aFnw5dx1xVYYQOf6YEnQ6aNdHbfRq3yVmhBJgEO8fVi IgVA+iqb2xxJxkbMOLfl74hmAqVksBsjHYcVZVvBouHeirAbBPA8ammWA3uGRTDa/iSA foYw== X-Gm-Message-State: AElRT7Gsc8DJZlVx2SwYSPElvVgxliqYEiwJm5Gg6jA84hlzY/3P1oP9 SVraXhdEolrpyUlgab5BYhsVrtiE X-Google-Smtp-Source: AG47ELs9SqYbG9pBhSQ5DRg5f7IOeQwoIPbEDpSC7+bLva3kAbOTGJSUU1A4plOZLEY9ks3RMlFXZw== X-Received: by 10.28.144.82 with SMTP id s79mr3890850wmd.4.1521290881568; Sat, 17 Mar 2018 05:48:01 -0700 (PDT) Received: from [192.168.178.32] (p2E530C99.dip0.t-ipconnect.de. [46.83.12.153]) by smtp.gmail.com with ESMTPSA id f14sm10743581wmi.11.2018.03.17.05.48.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Mar 2018 05:48:00 -0700 (PDT) Date: Sat, 17 Mar 2018 12:55:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <87605v0zq9.fsf@linaro.org> References: <87605v0zq9.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Don't try to vectorise COND_EXPR reduction chains (PR 84913) To: gcc-patches@gcc.gnu.org,Richard Sandiford From: Richard Biener Message-ID: <3E34B0CE-4788-48DA-80EA-551A7C269B30@gmail.com> X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00841.txt.bz2 On March 17, 2018 11:21:18 AM GMT+01:00, Richard Sandiford wrote: >The testcase ICEd for both SVE and AVX512 because we were trying >to vectorise a chain of COND_EXPRs as a reduction and getting >confused by reduc_index =3D=3D -1. > >We normally handle reduction chains by vectorising all statements >except the last one normally, but that wouldn't work here for the >reasons explained in the comment. > >Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? OK.=20 Richard.=20 >Richard > > >2018-03-17 Richard Sandiford > >gcc/ > PR tree-optimization/84913 > * tree-vect-loop.c (vectorizable_reduction): Don't try to > vectorize chains of COND_EXPRs. > >gcc/testsuite/ > PR tree-optimization/84913 > * gfortran.dg/vect/pr84913.f90: New test. > >Index: gcc/tree-vect-loop.c >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >--- gcc/tree-vect-loop.c 2018-03-01 08:20:43.850526185 +0000 >+++ gcc/tree-vect-loop.c 2018-03-17 10:19:19.289947549 +0000 >@@ -6788,6 +6788,30 @@ vectorizable_reduction (gimple *stmt, gi >/* If we have a condition reduction, see if we can simplify it further. > */ > if (v_reduc_type =3D=3D COND_REDUCTION) > { >+ /* TODO: We can't yet handle reduction chains, since we need to >treat >+ each COND_EXPR in the chain specially, not just the last one. >+ E.g. for: >+ >+ x_1 =3D PHI >+ x_2 =3D a_2 ? ... : x_1; >+ x_3 =3D a_3 ? ... : x_2; >+ >+ we're interested in the last element in x_3 for which a_2 || a_3 >+ is true, whereas the current reduction chain handling would >+ vectorize x_2 as a normal VEC_COND_EXPR and only treat x_3 >+ as a reduction operation. */ >+ if (reduc_index =3D=3D -1) >+ { >+ if (dump_enabled_p ()) >+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, >+ "conditional reduction chains not supported\n"); >+ return false; >+ } >+ >+ /* vect_is_simple_reduction ensured that operand 2 is the >+ loop-carried operand. */ >+ gcc_assert (reduc_index =3D=3D 2); >+ > /* Loop peeling modifies initial value of reduction PHI, which > makes the reduction stmt to be transformed different to the > original stmt analyzed. We need to record reduction code for >Index: gcc/testsuite/gfortran.dg/vect/pr84913.f90 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >--- /dev/null 2018-03-17 08:19:33.716019995 +0000 >+++ gcc/testsuite/gfortran.dg/vect/pr84913.f90 2018-03-17 >10:19:19.286947657 +0000 >@@ -0,0 +1,13 @@ >+! { dg-do compile } >+ >+function foo(a, b, c, n) >+ integer :: a(n), b(n), c(n), n, i, foo >+ foo =3D 0 >+ do i =3D 1, n >+ if (a(i) .eq. b(i)) then >+ foo =3D 1 >+ else if (a(i) .eq. c(i)) then >+ foo =3D 2 >+ end if >+ end do >+end function foo