From patchwork Thu Feb 17 05:31:26 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: liuhongt X-Patchwork-Id: 1593992 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=u1561mrJ; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Jzk3M6dWPz9s0r for ; Thu, 17 Feb 2022 16:31:58 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CF1123858032 for ; Thu, 17 Feb 2022 05:31:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CF1123858032 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1645075914; bh=yjKcz+GK6oFuD5+aeOMWysBpTQb+ZJbZaTM+bXJYV3I=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=u1561mrJSY0jQfFkUVBgC/CjOUUTlujB2U8w9wi5ejZgQikyWhlDXFMGPNIe9pl/z UPLVDb797ovvR6otWVBiexJEqU5BE0+QSdILNwuM3Ndca4IvHujW+yuN5F2ZcqkYWg nVoztKRDIJTMGKFgFjOf/wJCe7UOlQocUIogIof4= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by sourceware.org (Postfix) with ESMTPS id 974A83858D20 for ; Thu, 17 Feb 2022 05:31:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 974A83858D20 X-IronPort-AV: E=McAfee;i="6200,9189,10260"; a="248396194" X-IronPort-AV: E=Sophos;i="5.88,375,1635231600"; d="scan'208";a="248396194" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2022 21:31:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,375,1635231600"; d="scan'208";a="529955445" Received: from scymds01.sc.intel.com ([10.148.94.138]) by orsmga007.jf.intel.com with ESMTP; 16 Feb 2022 21:31:28 -0800 Received: from shliclel051.sh.intel.com (shliclel051.sh.intel.com [10.239.236.51]) by scymds01.sc.intel.com with ESMTP id 21H5VRAc004900; Wed, 16 Feb 2022 21:31:27 -0800 To: gcc-patches@gcc.gnu.org Subject: [PATCH V2] Restrict the two sources of vect_recog_cond_expr_convert_pattern to be of the same type when convert is extension. Date: Thu, 17 Feb 2022 13:31:26 +0800 Message-Id: <20220217053126.49814-1-hongtao.liu@intel.com> X-Mailer: git-send-email 2.18.1 In-Reply-To: References: X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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-Patchwork-Original-From: liuhongt via Gcc-patches From: liuhongt Reply-To: liuhongt Cc: jakub@redhat.com Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" > I find this quite unreadable, it looks like if @2 and @3 are treated > differently. I think keeping the old 3 lines and just adding > && (TYPE_PRECISION (TREE_TYPE (@0)) >= TYPE_PRECISION (type) > || (TYPE_UNSIGNED (TREE_TYPE (@2)) > == TYPE_UNSIGNED (TREE_TYPE (@3)))) > after it ideally with a comment why would be better. Update patch. gcc/ChangeLog: PR tree-optimization/104551 PR tree-optimization/103771 * match.pd (cond_expr_convert_p): Add types_match check when convert is extension. * tree-vect-patterns.cc (gimple_cond_expr_convert_p): Adjust comments. (vect_recog_cond_expr_convert_pattern): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr104551.c: New test. --- gcc/match.pd | 6 ++++++ gcc/testsuite/gcc.target/i386/pr104551.c | 24 ++++++++++++++++++++++++ gcc/tree-vect-patterns.cc | 6 ++++-- 3 files changed, 34 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gcc.target/i386/pr104551.c diff --git a/gcc/match.pd b/gcc/match.pd index 05a10ab6bfd..8b6f22f1065 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -7698,5 +7698,11 @@ and, == TYPE_PRECISION (TREE_TYPE (@2)) && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@3)) + /* For vect_recog_cond_expr_convert_pattern, @2 and @3 can differ in + signess when convert is truncation, but not ok for extension since + it's sign_extend vs zero_extend. */ + && (TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (type) + || (TYPE_UNSIGNED (TREE_TYPE (@2)) + == TYPE_UNSIGNED (TREE_TYPE (@3)))) && single_use (@4) && single_use (@5)))) diff --git a/gcc/testsuite/gcc.target/i386/pr104551.c b/gcc/testsuite/gcc.target/i386/pr104551.c new file mode 100644 index 00000000000..6300f25c0d5 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/pr104551.c @@ -0,0 +1,24 @@ +/* { dg-do run } */ +/* { dg-options "-O3 -mavx2" } */ +/* { dg-require-effective-target avx2 } */ + +unsigned int +__attribute__((noipa)) +test(unsigned int a, unsigned char p[16]) { + unsigned int res = 0; + for (unsigned b = 0; b < a; b += 1) + res = p[b] ? p[b] : (char) b; + return res; +} + +int main () +{ + unsigned int a = 16U; + unsigned char p[16]; + for (int i = 0; i != 16; i++) + p[i] = (unsigned char)128; + unsigned int res = test (a, p); + if (res != 128) + __builtin_abort (); + return 0; +} diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc index a8f96d59643..217bdfd7045 100644 --- a/gcc/tree-vect-patterns.cc +++ b/gcc/tree-vect-patterns.cc @@ -929,8 +929,10 @@ vect_reassociating_reduction_p (vec_info *vinfo, with conditions: 1) @1, @2, c, d, a, b are all integral type. 2) There's single_use for both @1 and @2. - 3) a, c and d have same precision. + 3) a, c have same precision. 4) c and @1 have different precision. + 5) c, d are the same type or they can differ in sign when convert is + truncation. record a and c and d and @3. */ @@ -952,7 +954,7 @@ extern bool gimple_cond_expr_convert_p (tree, tree*, tree (*)(tree)); TYPE_PRECISION (TYPE_E) != TYPE_PRECISION (TYPE_CD); TYPE_PRECISION (TYPE_AB) == TYPE_PRECISION (TYPE_CD); single_use of op_true and op_false. - TYPE_AB could differ in sign. + TYPE_AB could differ in sign when (TYPE_E) A is a truncation. Input: