From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 2FBFF3858D35 for ; Fri, 31 Jul 2020 11:38:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2FBFF3858D35 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="355704564" Received: from 85-171-191-139.rev.numericable.fr (HELO stedding) ([85.171.191.139]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2020 13:38:40 +0200 Date: Fri, 31 Jul 2020 13:38:37 +0200 (CEST) From: Marc Glisse X-X-Sender: glisse@stedding.saclay.inria.fr To: Richard Sandiford cc: gcc-patches@gcc.gnu.org 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; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, 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:38:44 -0000 On Fri, 31 Jul 2020, Richard Sandiford wrote: > Marc Glisse writes: >> +/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */ >> + (simplify >> + (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4)) >> + (with >> + { >> + tree rhs1, rhs2 = NULL; >> + rhs1 = fold_binary (op, type, @1, @3); >> + if (rhs1 && is_gimple_val (rhs1)) >> + rhs2 = fold_binary (op, type, @2, @4); >> + } >> + (if (rhs2 && is_gimple_val (rhs2)) >> + (vec_cond @0 { rhs1; } { rhs2; }))))) >> +#endif > > This one looks dangerous for potentially-trapping ops. I would expect the operation not to be folded if it can trap. Is that too optimistic? >> +/* (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? My memory of this dates from before the avx512-related changes, but at least at the time, the type of the condition in vec_cond_expr had to have the same size and number of elements as the result, and have signed integral elements. Now the size constraint has changed, but it still looks like for a given number of elements and size (this last one ignored for avx512), there is essentially a single type that can appear as condition. Is this wrong for x86? For SVE? I could add some types_match conditions if that seems too unsafe... -- Marc Glisse