From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9768 invoked by alias); 10 Feb 2020 14:40:33 -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 9760 invoked by uid 89); 10 Feb 2020 14:40:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.8 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= X-HELO: mail-lj1-f196.google.com Received: from mail-lj1-f196.google.com (HELO mail-lj1-f196.google.com) (209.85.208.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Feb 2020 14:40:31 +0000 Received: by mail-lj1-f196.google.com with SMTP id x14so7390511ljd.13 for ; Mon, 10 Feb 2020 06:40:31 -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=ivAe8zdYx31bOvCT4IOkRBipKrt5hQOC1dEC2d3pnNQ=; b=JsNMfq0Kwcx2SCqU0V547jFUgCr40eIxl4A19+99bwh69uZE64S5EnhMiH0OXhjic3 6KUt/plIebKsNQx6OMzEpGQ8mQXyABJKXhCzr6D+8zhkN1Nv71YWv11hXk5Uv8yohWhF D117yzctIJ7I38f5WzY+aCDwFUfe0T51ycQyRiqLJFCRGnQ913f4WZDFTxbiBERvOLHf DA2+7YxenJjoED0Aj1SpDAZoYJRaG/oF3WaNvzEy2Qo5lM8VUp7t2Crmf3rcK8pOY27p D2dlgrX37sodUputjfjoZuJNkioZDK53nhvOyc1+BGBi5QCokEEseksgq479aa5SRV+0 9q/w== MIME-Version: 1.0 References: <20200210143247.GQ17695@tucnak> In-Reply-To: <20200210143247.GQ17695@tucnak> From: Richard Biener Date: Mon, 10 Feb 2020 14:40:00 -0000 Message-ID: Subject: Re: [PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637] To: Jakub Jelinek Cc: Uros Bizjak , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00548.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. Hmm. Maybe with FP operands we can also try to implement the mask as != 0.0 FP condition? Not sure if -1 (or 1) is enough non-NaNish to not cause problems of course. > 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. > > --- 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 >