From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109205 invoked by alias); 4 Mar 2019 22:01:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 109176 invoked by uid 89); 4 Mar 2019 22:01:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=what=e2, visited?= X-HELO: userp2130.oracle.com Received: from userp2130.oracle.com (HELO userp2130.oracle.com) (156.151.31.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Mar 2019 22:01:15 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x24Lxnvi048627; Mon, 4 Mar 2019 22:01:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=PPTwxaLtvmPGKJnmfsHlnvcI9NP50O40zkpDHWWyePM=; b=gPB3AXFLaJHwC6ZqllbKGa8qSxg5WQZpp7P+fOBb7vOujqrubonM0xlCtCUWjp+Z0hPm YT16fjDhWCqpspKb7xZVtHDf8/ijrrP/Bzp9RPibSf1iHon/7knKLDnvWL3tbBmyZuV2 RhoRilINI28muQjM8z5OoJa6WX47Hqikumeaih/Cz74QELeD/e5IVK11cnWtxPThNaDT HA1981OYh5U4f9FRqwnL0uuhhiPtad2RqyMQvq9dqm1W2lvysRpkKj1AiMNlYKL1BwFM Y2vByx5XXKWtx37HUdekF8yb11M1ca8Q5DR6zU+HJL9BaQHrEmP1n2gJldUW1ZDeRHri hQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2qyh8u1hx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 Mar 2019 22:01:13 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x24M1Ck0011408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Mar 2019 22:01:12 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x24M1Bd4022867; Mon, 4 Mar 2019 22:01:12 GMT Received: from dhcp-10-159-134-147.vpn.oracle.com (/10.159.134.147) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Mar 2019 14:01:11 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A bug in vrp_meet? From: Qing Zhao In-Reply-To: Date: Mon, 04 Mar 2019 22:01:00 -0000 Cc: GCC Development , Jeff Law , gcc Patches Content-Transfer-Encoding: quoted-printable Message-Id: <81846359-36B4-46F1-9C5C-8E20F927FE9F@oracle.com> References: <933b52ac-d372-f9d9-792e-4166f35b41f5@redhat.com> <327DC916-C1B4-47F9-92AE-468236D32C1F@oracle.com> To: Richard Biener X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00025.txt.bz2 Hi, Richard, > On Mar 4, 2019, at 5:45 AM, Richard Biener w= rote: >>=20 >> It looks like DOM fails to visit stmts generated by simplification. Can = you open a bug report with a testcase? >>=20 >>=20 >> The problem is, It took me quite some time in order to come up with a sm= all and independent testcase for this problem, >> a little bit change made the error disappear. >>=20 >> do you have any suggestion on this? or can you give me some hint on how= to fix this in DOM? then I can try the fix on my side? >=20 > I remember running into similar issues in the past where I tried to > extract temporary nonnull ranges from divisions. > I have there >=20 > @@ -1436,11 +1436,16 @@ dom_opt_dom_walker::before_dom_children > m_avail_exprs_stack->pop_to_marker (); >=20 > edge taken_edge =3D NULL; > - for (gsi =3D gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi)) > - { > - evrp_range_analyzer.record_ranges_from_stmt (gsi_stmt (gsi), false= ); > - taken_edge =3D this->optimize_stmt (bb, gsi); > - } > + gsi =3D gsi_start_bb (bb); > + if (!gsi_end_p (gsi)) > + while (1) > + { > + evrp_range_analyzer.record_def_ranges_from_stmt (gsi_stmt (gsi), = false); > + taken_edge =3D this->optimize_stmt (bb, &gsi); > + if (gsi_end_p (gsi)) > + break; > + evrp_range_analyzer.record_use_ranges_from_stmt (gsi_stmt (gsi)); > + } >=20 > /* Now prepare to process dominated blocks. */ > record_edge_info (bb); >=20 > OTOH the issue in your case is that fold emits new stmts before gsi but t= he > above loop will never look at them. See tree-ssa-forwprop.c for code how > to deal with this (setting a pass-local flag on stmts visited and walking= back > to unvisited, newly inserted ones). The fold_stmt interface could in the= ory > also be extended to insert new stmts on a sequence passed to it so the > caller would be responsible for inserting them into the IL and could then > more easily revisit them (but that's a bigger task). >=20 > So, does the following help? Yes, this change fixed the error in my side, now, in the dumped file for pa= ss dom3: =3D=3D=3D=3D Visiting statement: i_49 =3D _98 > 0 ? k_105 : 0; Meeting [0, 65535] and [0, 0] to [0, 65535] Intersecting [0, 65535] and [0, 65535] to [0, 65535] Optimizing statement i_49 =3D _98 > 0 ? k_105 : 0; Replaced 'k_105' with variable '_98' gimple_simplified to _152 =3D MAX_EXPR <_98, 0>; i_49 =3D _152; Folded to: i_49 =3D _152; LKUP STMT i_49 =3D _152 =3D=3D=3D=3D ASGN i_49 =3D _152 Visiting statement: _152 =3D MAX_EXPR <_98, 0>; Visiting statement: i_49 =3D _152; Intersecting [0, 65535] EQUIVALENCES: { _152 } (1 elements) and [0, 65535] to [0, 65535] EQUIVALENCES: { _152 } (1 elements) =3D=3D=3D=3D We can clearly see from the above, all the new stmts generated by fold are = visited now.=20 it is also confirmed that the runtime error caused by this bug was gone wit= h this fix. So, what=E2=80=99s the next step for this issue? will you commit this fix to gcc9 and gcc8 (we need it in gcc8)? or I can test this fix on my side and commit it to both gcc9 and gcc8? thanks. Qing >=20 > Index: gcc/tree-ssa-dom.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- gcc/tree-ssa-dom.c (revision 269361) > +++ gcc/tree-ssa-dom.c (working copy) > @@ -1482,8 +1482,25 @@ dom_opt_dom_walker::before_dom_children > edge taken_edge =3D NULL; > for (gsi =3D gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi)) > { > + gimple_stmt_iterator pgsi =3D gsi; > + gsi_prev (&pgsi); > evrp_range_analyzer.record_ranges_from_stmt (gsi_stmt (gsi), false); > taken_edge =3D this->optimize_stmt (bb, gsi); > + gimple_stmt_iterator npgsi =3D gsi; > + gsi_prev (&npgsi); > + /* Walk new stmts eventually inserted by DOM. gsi_stmt (gsi) itse= lf > + while it may be changed should not have gotten a new definition.= */ > + if (gsi_stmt (pgsi) !=3D gsi_stmt (npgsi)) > + do > + { > + if (gsi_end_p (pgsi)) > + pgsi =3D gsi_start_bb (bb); > + else > + gsi_next (&pgsi); > + evrp_range_analyzer.record_ranges_from_stmt (gsi_stmt (pgsi), > + false); > + } > + while (gsi_stmt (pgsi) !=3D gsi_stmt (gsi)); > } >=20 > /* Now prepare to process dominated blocks. */ >=20 >=20 > Richard. >=20 >> Thanks a lot. >>=20 >> Qing >>=20 >>=20 >>=20 >> Richard. >>=20 >>=20