From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <richard.sandiford@arm.com>
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
 by sourceware.org (Postfix) with ESMTP id 92F8F3858D35
 for <gcc-patches@gcc.gnu.org>; Fri, 31 Jul 2020 11:18:17 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 92F8F3858D35
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=arm.com
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=richard.sandiford@arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
 by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 509811FB;
 Fri, 31 Jul 2020 04:18:17 -0700 (PDT)
Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126])
 by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D120F3F71F;
 Fri, 31 Jul 2020 04:18:16 -0700 (PDT)
From: Richard Sandiford <richard.sandiford@arm.com>
To: Marc Glisse <marc.glisse@inria.fr>
Mail-Followup-To: Marc Glisse <marc.glisse@inria.fr>, gcc-patches@gcc.gnu.org,
 richard.sandiford@arm.com
Cc: gcc-patches@gcc.gnu.org
Subject: Re: VEC_COND_EXPR optimizations
References: <alpine.DEB.2.23.453.2007291859410.6927@stedding.saclay.inria.fr>
Date: Fri, 31 Jul 2020 12:18:15 +0100
In-Reply-To: <alpine.DEB.2.23.453.2007291859410.6927@stedding.saclay.inria.fr>
 (Marc Glisse's message of "Thu, 30 Jul 2020 09:49:10 +0200 (CEST)")
Message-ID: <mptbljwaq6g.fsf@arm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2020 11:18:18 -0000

Marc Glisse <marc.glisse@inria.fr> 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.

> +/* (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?
Same question for the later folds.

Thanks,
Richard