From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) by sourceware.org (Postfix) with ESMTPS id B5D103858431 for ; Thu, 17 Feb 2022 01:22:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B5D103858431 Received: by mail-vs1-xe2d.google.com with SMTP id g21so4543392vsp.6 for ; Wed, 16 Feb 2022 17:22:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wHcl/cADrs44QWePfXbmAhZyNqMsyzr96X4eIFKvBeU=; b=0j4TO0rldTJCu5lEVlVE9iq6efE52t4bA/M7lFQQQ6rUHK/3CITHDGyRnRho2i724r pjuxr+HLUf8x3z/5zga2Bv56b8bVSYq3zoh6UyfwprXiAWFrZNsW71l9Y4M/WGalSrMr ygn7+CmGwaNSce7GskXTGMkThE7TU+OkKhrLSl8+mTZBceDrYeZKr6V83HSnTCEfYvy8 NfYGqD5oIYI3uc+XsAaFyNdpcsFigg9YYFZGD1+Hv+8iJ5oPq/D9hjatBjFKlm8OZ7a6 If0yPruOOt6ztABHOTzWUP/SMbtuBudDI1zkKphZGbSUkdtWp2/JvqSZc+oxryEzEJdL i2Zg== X-Gm-Message-State: AOAM531BXPz3mpQIjy3MoZ97kJ6sn4JZxtbq+7O9qEIDs8uSlJu5qg1O 9+3mWrku7e7TV1MSNWU5EA2BKEFuBO7bx7oYRBs= X-Google-Smtp-Source: ABdhPJzHFTyJ7WFlDB9e8xE6eeXyHbiMPhFiqwOy2oUGm52FPwzyJR2OaIAnmpQABofWB5RfDrpZNgxp1Y8wF5AsN28= X-Received: by 2002:a67:c387:0:b0:31b:d4c8:264f with SMTP id s7-20020a67c387000000b0031bd4c8264fmr195899vsj.76.1645060932268; Wed, 16 Feb 2022 17:22:12 -0800 (PST) MIME-Version: 1.0 References: <20220216090309.82939-1-hongtao.liu@intel.com> <20220216141540.GZ2646553@tucnak> In-Reply-To: <20220216141540.GZ2646553@tucnak> From: Hongtao Liu Date: Thu, 17 Feb 2022 09:30:35 +0800 Message-ID: Subject: Re: [PATCH] Restrict the two sources of vect_recog_cond_expr_convert_pattern to be of the same type when convert is extension. To: Jakub Jelinek Cc: liuhongt , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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-List-Received-Date: Thu, 17 Feb 2022 01:22:19 -0000 On Wed, Feb 16, 2022 at 10:17 PM Jakub Jelinek via Gcc-patches wrote: > > On Wed, Feb 16, 2022 at 05:03:09PM +0800, liuhongt via Gcc-patches wrote: > > > > +(match (cond_expr_convert_p @0 @2 @3 @6) > > > > + (cond (simple_comparison@6 @0 @1) (convert@4 @2) (convert@5 @3)) > > > > + (if (types_match (TREE_TYPE (@2), TREE_TYPE (@3)) > > > > > > But in principle @2 or @3 could safely differ in sign, you'd then need to ensure > > > to insert sign conversions to @2/@3 to the signedness of @4/@5. > > > > > It turns out differ in sign is not suitable for extension(but ok for truncation), > > because it's zero_extend vs sign_extend. > > > > The patch add types_match check when convert is extension. > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > > And native Bootstrapped and regtested on CLX. > > > > Ok for trunk? > > > > 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 | 8 +++++--- > > gcc/testsuite/gcc.target/i386/pr104551.c | 24 ++++++++++++++++++++++++ > > gcc/tree-vect-patterns.cc | 6 ++++-- > > 3 files changed, 33 insertions(+), 5 deletions(-) > > create mode 100644 gcc/testsuite/gcc.target/i386/pr104551.c > > > > diff --git a/gcc/match.pd b/gcc/match.pd > > index 05a10ab6bfd..8e80b9f1576 100644 > > --- a/gcc/match.pd > > +++ b/gcc/match.pd > > @@ -7692,11 +7692,13 @@ and, > > (if (INTEGRAL_TYPE_P (type) > > && INTEGRAL_TYPE_P (TREE_TYPE (@2)) > > && INTEGRAL_TYPE_P (TREE_TYPE (@0)) > > - && INTEGRAL_TYPE_P (TREE_TYPE (@3)) > > && TYPE_PRECISION (type) != TYPE_PRECISION (TREE_TYPE (@0)) > > && TYPE_PRECISION (TREE_TYPE (@0)) > > == TYPE_PRECISION (TREE_TYPE (@2)) > > - && TYPE_PRECISION (TREE_TYPE (@0)) > > - == TYPE_PRECISION (TREE_TYPE (@3)) > > + && (types_match (TREE_TYPE (@2), TREE_TYPE (@3)) > > + || ((TYPE_PRECISION (TREE_TYPE (@0)) > > + == TYPE_PRECISION (TREE_TYPE (@3))) > > + && INTEGRAL_TYPE_P (TREE_TYPE (@3)) > > + && TYPE_PRECISION (TREE_TYPE (@3)) > TYPE_PRECISION (type))) > > && single_use (@4) > > && single_use (@5)))) > > 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)))) Yes, good idea. > after it ideally with a comment why would be better. > Note, if the precision of @0 and type is the same, I think signedness can > still differ, no? We have TYPE_PRECISION (type) != TYPE_PRECISION (TREE_TYPE (@0)). > > Jakub > -- BR, Hongtao