From patchwork Mon May 23 13:06:09 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roger Sayle X-Patchwork-Id: 54284 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 97816383A61D for ; Mon, 23 May 2022 13:06:28 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [162.254.253.69]) by sourceware.org (Postfix) with ESMTPS id 8BFD5383F940 for ; Mon, 23 May 2022 13:06:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BFD5383F940 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Type:MIME-Version:Message-ID: Date:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+KMqEL1mWfpGXJP+Yvo6+WwZn3iMSAj8ItPb0RC5Ip4=; b=UOGrXgRsxV1670Zrt7zyTD9aBs AyfCZl7RyQ0kJD83AvploiKHk3vEPjoboT1W2nc6zOuOwwjBfjp/gs1y90u9G+8kXJeox0q/AsOnl rDn1Sqm+XpGuT3GGqDOTHtwV90AGdHArOvWmJZRFM22v93Z+RWHbo8CoF5orQr3ffe/Rd23CF4LVv OqO6hd/KcS1H1unViwsvVS2rbvP4cSMAPXdM9cFX4/HcdFrDsKxfHplkh7ONQWjRDttlWXobj7BJi Ee/ZIId5dEOhIvAm2QCdQ3BDiyCbM0DAgj37MbyJaBqNBK3bOAMZGIyj0Ck/glIUA/JBTZWk45z1Y tKyl4X4w==; Received: from host109-154-46-241.range109-154.btcentralplus.com ([109.154.46.241]:51895 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nt7lD-0002HY-0b; Mon, 23 May 2022 09:06:11 -0400 From: "Roger Sayle" To: Subject: [PATCH/RFC] PR tree-optimization/96912: Recognize VEC_COND_EXPR in match.pd Date: Mon, 23 May 2022 14:06:09 +0100 Message-ID: <005701d86ea5$dfc134f0$9f439ed0$@nextmovesoftware.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdhupPXSbahPdicmRj+Z9mZE7UVfgQ== Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi Richard, I was wondering what you think of the following patch as a solution to PR tree-optimization/96912, i.e. the ability to recognize pblendvb from regular code rather than as a target specific builtin? The obvious point of contention is that the current middle-end philosophy around vector expressions is that the middle-end should continually check for backend support, whereas I prefer the "old school" view that trees are an abstraction and that RTL expansion is the point where these abstract operations get converted/lowered into instructions supported by the target. [The exceptions being built-in functions, IFN_* etc.] Should tree.texi document which tree codes can't be used without checking the backend. Bootstrapped and regression tested, but this obviously depends upon RTL expansion being able to perform the inverse operation/lowering if required. 2022-05-23 Roger Sayle gcc/ChangeLog PR tree-optimization/96912 * match.pd (vector_mask_p): New predicate to identify vectors where every element must be zero or all ones. (bit_xor (bit_and (bit_xor ...) ...) ...): Recognize a VEC_COND_EXPR expressed as logical vector operations. gcc/testsuite/ChangeLog PR tree-optimization/96912 * gcc.target/i386/pr96912.c: New test case. Thoughts? How would you solve this PR? Are there convenience predicates for testing whether a target supports vec_cond_expr, vec_duplicate, etc? Cheers, Roger --- /* { dg-do compile { target { ! ia32 } } } */ /* { dg-options "-O2 -msse4" } */ typedef char V __attribute__((vector_size(16))); typedef long long W __attribute__((vector_size(16))); W foo (W x, W y, V m) { W t = (m < 0); return (~t & x) | (t & y); } V bar (V x, V y, V m) { V t = (m < 0); return (~t & x) | (t & y); } /* { dg-final { scan-assembler-times "pblend" 2 } } */ diff --git a/gcc/match.pd b/gcc/match.pd index c2fed9b..e365f28 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -4221,6 +4221,35 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (if (integer_all_onesp (@1) && integer_zerop (@2)) @0)))) +/* A integer vector where every element must be 0 or -1. */ +(match vector_mask_p + @0 + (if (VECTOR_BOOLEAN_TYPE_P (type)))) +(match vector_mask_p + VECTOR_CST@0 + (if (integer_zerop (@0) || integer_all_onesp (@0)))) +(match vector_mask_p + (vec_cond @0 vector_mask_p@1 vector_mask_p@2)) +(match vector_mask_p + (bit_not vector_mask_p@0)) +(for op (bit_and bit_ior bit_xor) + (match vector_mask_p + (op vector_mask_p@0 vector_mask_p@1))) + +/* Recognize VEC_COND_EXPR. */ +(simplify + (bit_xor:c (bit_and:c (bit_xor:c @0 @1) (view_convert vector_mask_p@2)) @0) + (if (VECTOR_TYPE_P (type) + && VECTOR_TYPE_P (TREE_TYPE (@2))) + (with { tree masktype = truth_type_for (TREE_TYPE (@2)); + tree vecttype = maybe_ne (TYPE_VECTOR_SUBPARTS (masktype), + TYPE_VECTOR_SUBPARTS (type)) + ? unsigned_type_for (masktype) + : type; } + (view_convert (vec_cond:vecttype (view_convert:masktype @2) + (view_convert:vecttype @1) + (view_convert:vecttype @0)))))) + /* A few simplifications of "a ? CST1 : CST2". */ /* NOTE: Only do this on gimple as the if-chain-to-switch optimization depends on the gimple to have if statements in it. */