Message ID | Y+3rUiUVywYfwfDE@tucnak |
---|---|
State | Unresolved |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp182437wrn; Thu, 16 Feb 2023 00:39:07 -0800 (PST) X-Google-Smtp-Source: AK7set9M6M7L+WhhP3NvkfaKZOiEA990XhuvNi1kytD1JOEszHolYF4GA1WvTkWJ+sAgl4nLtF72 X-Received: by 2002:a17:906:8a54:b0:88f:79e7:8305 with SMTP id gx20-20020a1709068a5400b0088f79e78305mr6213006ejc.63.1676536747334; Thu, 16 Feb 2023 00:39:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676536747; cv=none; d=google.com; s=arc-20160816; b=S6+AO0GXn61qlX3uaX40vuZVBgSDaBcBeBGOiNGLLGZD/vDTy4rA9TcUK5Is4KmDDS CXDBIN9OiHrota70ODdaagHXBGVH2U2MRkOs31ga9ohU5XdWpkxg6Th5VouGTRCiKXaf +LUIAcjX4502AIlHK2YRciIslmyX3GS9h22DDu2NgjnpqNw2Ci041B3lBvdtJ+JHeuF4 P5MDAezVETcNn9S8WECkX7jFfnszeGaG6MhmBh8C5cM6ASfe8fgNETx6IxykuYVujawM sbT2L3Y8iLTfGgWPIweWriqElgwCaqyWgZdC/d8e283VByrTJ3ojlLCOdboi32RDbd9R oxVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-disposition:mime-version:message-id:subject:cc:to:date :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=dTbWbEKQ4FWQMHocE82e+NXdkyUCxtXg9foWDRTSR9Y=; b=DB0SXHbq91i/gpntKZiEzZrKbSZ+k5Duaa0TN2a2Wz9aNdb0gRbZ/VYY81AIZh/pgM zNPjFfWUrjQcDH5fV1MSOyIXAanzdLO8CANdOCLWLPmOXrB+DmgMzMmOiH1KcRfYZKtJ Ianwn1AQ80ulFJE0aV+F+pPj9jrGYDtdeaTVd8gta8WResma/pvPEowATs7nGZqJ391J yiCni6Ppt2eSPKWHWu2fyIH9GUBqYr5/PxbjFRxqvY374CCEqtYqkJRBsKKaabp71i/v IYIeDCTUjvtnszKJKnRfK8jH/pw7RS/qfCQ6+a8CXj0Nw3L/pGCQ+b+QhnqeIBzpsBlF uGBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="Q5KIwJ/S"; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id vz24-20020a17090704d800b008b138d8c1bbsi1367833ejb.54.2023.02.16.00.39.07 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Feb 2023 00:39:07 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="Q5KIwJ/S"; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EF402385B527 for <ouuuleilei@gmail.com>; Thu, 16 Feb 2023 08:39:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF402385B527 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1676536743; bh=dTbWbEKQ4FWQMHocE82e+NXdkyUCxtXg9foWDRTSR9Y=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=Q5KIwJ/S5y+O9KBUQiYvw291XaQUCspn72pMG6iohQGYiLM/u51yqHrkE/J3GxgLI mPOItB7CaoeG9JrVT5MSJlfUBTc+OC2hmDdvWLBoMrxkLebiNhcuQQKNvUebPCobXO ql993R0vI63uFvMDK6Fqi/HXT/R55DGq9d7EFMzE= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B2915385841D for <gcc-patches@gcc.gnu.org>; Thu, 16 Feb 2023 08:37:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B2915385841D Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-497-2cm2cLgRN0exYcLGEwI6mw-1; Thu, 16 Feb 2023 03:37:42 -0500 X-MC-Unique: 2cm2cLgRN0exYcLGEwI6mw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4302385CBE7; Thu, 16 Feb 2023 08:37:42 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.203]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F2F2FC15BA0; Thu, 16 Feb 2023 08:37:41 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 31G8bdnY2901331 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 16 Feb 2023 09:37:39 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 31G8bckQ2901330; Thu, 16 Feb 2023 09:37:38 +0100 Date: Thu, 16 Feb 2023 09:37:38 +0100 To: Richard Biener <rguenther@suse.de> Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] reassoc: Fix up (ab) handling in eliminate_redundant_comparison [PR108783] Message-ID: <Y+3rUiUVywYfwfDE@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP 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 <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> From: Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jakub Jelinek <jakub@redhat.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757976196318866258?= X-GMAIL-MSGID: =?utf-8?q?1757976196318866258?= |
Series |
reassoc: Fix up (ab) handling in eliminate_redundant_comparison [PR108783]
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | warning | Git am fail log |
Commit Message
Jakub Jelinek
Feb. 16, 2023, 8:37 a.m. UTC
Hi! The following testcase ICEs because eliminate_redundant_comparison sees redundant comparisons in &&/|| where the comparison has (ab) SSA_NAME, maybe_fold_{and,or}_comparisons optimizes them into a single comparison and build_and_add_sum emits a new comparison close to the definition operands, which in this case is before a returns_twice call (which is invalid). Generally reassoc just punts on (ab) SSA_NAMEs, declares them non-reassociable etc., so the second half of this patch does that. Though we can do better in this case; the function has special code when maybe_fold_{and,or}_comparisons returns INTEGER_CST (false/true) or when what it returns is the same as curr->op (the first of the comparisons we are considering) - in that case we just remove the second one and keep the first one. The reason it doesn't match is that curr->op is a SSA_NAME whose SSA_NAME_DEF_STMT is checked to be a comparison, in this case _42 = a_1(ab) != 0 and the other comparison is also like that. maybe_fold_{and,or}_comparisons looks through the definitions though and so returns a_1(ab) != 0 as tree. So the first part of the patch checks whether that returned comparison isn't the same as the curr->op comparison and if yes, it just overrides t back to curr->op so that its SSA_NAME is reused. In that case we can handle even (ab) in {,new}op{1,2} because we don't create a new comparison of that, just keep using the existing one. And t can't be (ab) because otherwise it wouldn't be considered a reassociable operand. The (ab) checks are needed say when we have a_1(ab) == 42 || a_1(ab) > 42 kind of comparisons where maybe_fold_{and,or}_comparisons returns a new comparison not existing in the IL yet. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2023-02-15 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/108783 * tree-ssa-reassoc.cc (eliminate_redundant_comparison): If lcode is equal to TREE_CODE (t), op1 to newop1 and op2 to newop2, set t to curr->op. Otherwise, punt if either newop1 or newop2 are SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAMEs. * gcc.c-torture/compile/pr108783.c: New test. Jakub
Comments
On Thu, 16 Feb 2023, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs because eliminate_redundant_comparison sees > redundant comparisons in &&/|| where the comparison has (ab) SSA_NAME, > maybe_fold_{and,or}_comparisons optimizes them into a single comparison > and build_and_add_sum emits a new comparison close to the definition > operands, which in this case is before a returns_twice call (which is > invalid). Generally reassoc just punts on (ab) SSA_NAMEs, declares them > non-reassociable etc., so the second half of this patch does that. > > Though we can do better in this case; the function has special code > when maybe_fold_{and,or}_comparisons returns INTEGER_CST (false/true) > or when what it returns is the same as curr->op (the first of the > comparisons we are considering) - in that case we just remove the > second one and keep the first one. The reason it doesn't match is that > curr->op is a SSA_NAME whose SSA_NAME_DEF_STMT is checked to be a > comparison, in this case _42 = a_1(ab) != 0 and the other comparison > is also like that. maybe_fold_{and,or}_comparisons looks through the > definitions though and so returns a_1(ab) != 0 as tree. > So the first part of the patch checks whether that returned comparison > isn't the same as the curr->op comparison and if yes, it just overrides > t back to curr->op so that its SSA_NAME is reused. In that case we can > handle even (ab) in {,new}op{1,2} because we don't create a new comparison > of that, just keep using the existing one. And t can't be (ab) because > otherwise it wouldn't be considered a reassociable operand. > > The (ab) checks are needed say when we have a_1(ab) == 42 || a_1(ab) > 42 > kind of comparisons where maybe_fold_{and,or}_comparisons returns a new > comparison not existing in the IL yet. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. Thanks, Richard. > 2023-02-15 Jakub Jelinek <jakub@redhat.com> > > PR tree-optimization/108783 > * tree-ssa-reassoc.cc (eliminate_redundant_comparison): If lcode > is equal to TREE_CODE (t), op1 to newop1 and op2 to newop2, set > t to curr->op. Otherwise, punt if either newop1 or newop2 are > SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAMEs. > > * gcc.c-torture/compile/pr108783.c: New test. > > --- gcc/tree-ssa-reassoc.cc.jj 2023-01-12 21:04:08.726238049 +0100 > +++ gcc/tree-ssa-reassoc.cc 2023-02-15 13:28:04.987278895 +0100 > @@ -2272,6 +2272,15 @@ eliminate_redundant_comparison (enum tre > STRIP_USELESS_TYPE_CONVERSION (newop2); > if (!is_gimple_val (newop1) || !is_gimple_val (newop2)) > continue; > + if (lcode == TREE_CODE (t) > + && operand_equal_p (op1, newop1, 0) > + && operand_equal_p (op2, newop2, 0)) > + t = curr->op; > + else if ((TREE_CODE (newop1) == SSA_NAME > + && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (newop1)) > + || (TREE_CODE (newop2) == SSA_NAME > + && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (newop2))) > + continue; > } > > if (dump_file && (dump_flags & TDF_DETAILS)) > --- gcc/testsuite/gcc.c-torture/compile/pr108783.c.jj 2023-02-15 12:42:46.244340524 +0100 > +++ gcc/testsuite/gcc.c-torture/compile/pr108783.c 2023-02-15 13:24:47.515187118 +0100 > @@ -0,0 +1,42 @@ > +/* PR tree-optimization/108783 */ > + > +__attribute__((returns_twice)) int baz (int, int); > + > +int > +bar (int x) > +{ > + return x; > +} > + > +int > +foo (int x, int y) > +{ > + int a; > + > + a = bar (x); > + baz (x, y); > + > + return y && a && a; > +} > + > +int > +qux (int x, int y) > +{ > + int a; > + > + a = bar (x); > + baz (x, y); > + > + return y && a != 42 && a >= 42; > +} > + > +int > +corge (int x, int y) > +{ > + int a; > + > + a = bar (x); > + baz (x, y); > + > + return y || a == 42 || a > 42; > +} > > Jakub > >
--- gcc/tree-ssa-reassoc.cc.jj 2023-01-12 21:04:08.726238049 +0100 +++ gcc/tree-ssa-reassoc.cc 2023-02-15 13:28:04.987278895 +0100 @@ -2272,6 +2272,15 @@ eliminate_redundant_comparison (enum tre STRIP_USELESS_TYPE_CONVERSION (newop2); if (!is_gimple_val (newop1) || !is_gimple_val (newop2)) continue; + if (lcode == TREE_CODE (t) + && operand_equal_p (op1, newop1, 0) + && operand_equal_p (op2, newop2, 0)) + t = curr->op; + else if ((TREE_CODE (newop1) == SSA_NAME + && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (newop1)) + || (TREE_CODE (newop2) == SSA_NAME + && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (newop2))) + continue; } if (dump_file && (dump_flags & TDF_DETAILS)) --- gcc/testsuite/gcc.c-torture/compile/pr108783.c.jj 2023-02-15 12:42:46.244340524 +0100 +++ gcc/testsuite/gcc.c-torture/compile/pr108783.c 2023-02-15 13:24:47.515187118 +0100 @@ -0,0 +1,42 @@ +/* PR tree-optimization/108783 */ + +__attribute__((returns_twice)) int baz (int, int); + +int +bar (int x) +{ + return x; +} + +int +foo (int x, int y) +{ + int a; + + a = bar (x); + baz (x, y); + + return y && a && a; +} + +int +qux (int x, int y) +{ + int a; + + a = bar (x); + baz (x, y); + + return y && a != 42 && a >= 42; +} + +int +corge (int x, int y) +{ + int a; + + a = bar (x); + baz (x, y); + + return y || a == 42 || a > 42; +}