From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25401 invoked by alias); 10 Feb 2020 20:16:36 -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 25383 invoked by uid 89); 10 Feb 2020 20:16:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=richard's, richards, Richards, Richard's X-HELO: mail-io1-f68.google.com Received: from mail-io1-f68.google.com (HELO mail-io1-f68.google.com) (209.85.166.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Feb 2020 20:16:34 +0000 Received: by mail-io1-f68.google.com with SMTP id c16so9071036ioh.6 for ; Mon, 10 Feb 2020 12:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FyQ9oFcWusGLP4orL8Dn4L3JuEPo1Q0/Ic5ZVu5XLoM=; b=HV6yD5oK/MQe2Vij+aPVrw9xyReFm8RTOFiV3+qERgkBOApSa+RmtjSXeypMe5ofzV EPkQc/QWyr0peP2fgg4ti4EswOIbLWEJYoE2Yv4sqrXTcdEs2GQNI++MzBG0RXaMOxwe y5EnsABWfqHI+FmrM0HCEQU37hwSCfj1v+ddrz02c7RWxY/OLlgZz6cEPnbmDtum1VG/ ttxPU+G9iieRVW+6Oj2Ln5Yk0SYOwHj5I2vCyDAJ/Lx11ClMG5wMre6dKfUKyd70dahG PRCHP6BTAirouCCnxxJMOyIf7ZACJjy7R2Gk2ToTxDAtEzXHvOzkp679r1UrEZpTjICd TmGg== MIME-Version: 1.0 References: <20200210143247.GQ17695@tucnak> In-Reply-To: <20200210143247.GQ17695@tucnak> From: Uros Bizjak Date: Mon, 10 Feb 2020 20:16:00 -0000 Message-ID: Subject: Re: [PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637] To: Jakub Jelinek Cc: "gcc-patches@gcc.gnu.org" , Richard Biener Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2020-02/txt/msg00588.txt.bz2 On Mon, Feb 10, 2020 at 3:33 PM Jakub Jelinek wrote: > > Hi! > > As mentioned in the PR, for -mavx -mno-avx2 the backend does support > vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors > aren't much supported in that case, it is performed using > vandps/vandnps/vorps). The problem is that after the last generic vector > lowering (where the VEC_COND_EXPR still compares two V4DF vectors and > has two V4DI last operands and V4DI result and so is considered ok) fre4 > folds the condition into constant, at which point the middle-end during > expansion will try vcond_mask_optab and fall back to trying to expand it > as the constant vector < 0 vcondv4div4di, but neither of them is supported > for -mavx -mno-avx2 and thus we ICE. > > So, the options I see is either what the following patch does, also support > vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or > require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current > TARGET_AVX. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > Or do you prefer the disabling of the vcond patterns instead? > > 2020-02-10 Jakub Jelinek > > PR target/93637 > * config/i386/sse.md (VI_256_AVX2): New mode iterator. > (vcond_mask_): Use it instead of VI_256. > Change condition from TARGET_AVX2 to TARGET_AVX. > > * gcc.target/i386/avx-pr93637.c: New test. LGTM as an ICE fix for stage4. We can try Richard's suggestion "later". Thanks, Uros. > > --- gcc/config/i386/sse.md.jj 2020-02-10 13:14:02.970131692 +0100 > +++ gcc/config/i386/sse.md 2020-02-10 13:15:54.343473253 +0100 > @@ -3430,13 +3430,19 @@ (define_expand "vcond_mask_ (match_operand: 3 "register_operand")))] > "TARGET_AVX512BW") > > +;; As vcondv4div4df and vcondv8siv8sf are enabled already with TARGET_AVX, > +;; and their condition can be folded late into a constant, we need to > +;; support vcond_mask_v4div4di and vcond_mask_v8siv8si for TARGET_AVX. > +(define_mode_iterator VI_256_AVX2 [(V32QI "TARGET_AVX2") (V16HI "TARGET_AVX2") > + V8SI V4DI]) > + > (define_expand "vcond_mask_" > - [(set (match_operand:VI_256 0 "register_operand") > - (vec_merge:VI_256 > - (match_operand:VI_256 1 "nonimmediate_operand") > - (match_operand:VI_256 2 "nonimm_or_0_operand") > + [(set (match_operand:VI_256_AVX2 0 "register_operand") > + (vec_merge:VI_256_AVX2 > + (match_operand:VI_256_AVX2 1 "nonimmediate_operand") > + (match_operand:VI_256_AVX2 2 "nonimm_or_0_operand") > (match_operand: 3 "register_operand")))] > - "TARGET_AVX2" > + "TARGET_AVX" > { > ix86_expand_sse_movcc (operands[0], operands[3], > operands[1], operands[2]); > --- gcc/testsuite/gcc.target/i386/avx-pr93637.c.jj 2020-02-10 13:19:18.212437488 +0100 > +++ gcc/testsuite/gcc.target/i386/avx-pr93637.c 2020-02-10 13:18:25.651220171 +0100 > @@ -0,0 +1,17 @@ > +/* PR target/93637 */ > +/* { dg-do compile } */ > +/* { dg-options "-mavx -mno-avx2 -O3 --param sccvn-max-alias-queries-per-access=3" } */ > + > +double > +foo (void) > +{ > + int i; > + double r = 7.0; > + double a[] = { 0.0, 0.0, -0.0, 0.0, 0.0, -0.0, 1.0, 0.0, 0.0, -0.0, 1.0, 0.0, 1.0, 1.0 }; > + > + for (i = 0; i < sizeof (a) / sizeof (a[0]); ++i) > + if (a[i] == 0.0) > + r = a[i]; > + > + return r; > +} > > Jakub >