From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sourceware.org (Postfix) with ESMTPS id C987B3851C17 for ; Fri, 31 Jul 2020 11:57:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C987B3851C17 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=marc.glisse@inria.fr X-IronPort-AV: E=Sophos;i="5.75,418,1589234400"; d="scan'208";a="462029892" Received: from 85-171-191-139.rev.numericable.fr (HELO stedding) ([85.171.191.139]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2020 13:57:02 +0200 Date: Fri, 31 Jul 2020 13:57:02 +0200 (CEST) From: Marc Glisse X-X-Sender: glisse@stedding.saclay.inria.fr To: Richard Biener cc: Richard Sandiford , GCC Patches Subject: Re: VEC_COND_EXPR optimizations In-Reply-To: Message-ID: References: User-Agent: Alpine 2.23 (DEB 453 2020-06-18) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 11:57:05 -0000 On Fri, 31 Jul 2020, Richard Biener wrote: >>>> +/* (v ? w : 0) ? a : b is just (v & w) ? a : b */ >>>> +(simplify >>>> + (vec_cond (vec_cond:s @0 @3 integer_zerop) @1 @2) >>>> + (vec_cond (bit_and @0 @3) @1 @2)) >>> >>> Does something check automatically that @0 and @3 have compatible types? > > @0 should always have a vector boolean type and thus will not be generally > compatible with @3. But OTOH then when you see (vec_cond (vec_cond ... > then @3 must be vector boolean as well... > > But in theory with AVX512 the inner vec_cond could have a SImode > condition @0 producing a regular V4SImode vector mask for an outer > AVX512 SSE-style vec-cond and you then would get a mismatch. Ah, I thought the SSE-style vec_cond was impossible in AVX512 mode, at least I couldn't generate one in a few tests, but I didn't try very hard. > So indeed better add a type compatibility check. Ok, it can't hurt. -- Marc Glisse