From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3313 invoked by alias); 4 Mar 2019 11:45:48 -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 3297 invoked by uid 89); 4 Mar 2019 11:45:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=otoh, OTOH, walking, H*f:sk:ABC070F X-HELO: mail-lj1-f196.google.com Received: from mail-lj1-f196.google.com (HELO mail-lj1-f196.google.com) (209.85.208.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Mar 2019 11:45:41 +0000 Received: by mail-lj1-f196.google.com with SMTP id a17so4041002ljd.4; Mon, 04 Mar 2019 03:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0RRQSahp9kqTDDBoh+FKpFYAV9Fy7TR1GIiQoFnRx2c=; b=bmuhkOP5t1FAnCv3JX75Q54HJUdYtkHtjxh7wlZa09AbxTxr/aEsw5KNV+OmaiYF65 Jryg+RAoj2OJhAi8sFPx4ITzztZrpsiKpKXV43oedriaIV/a/uxiSuBqXk8j9ZQcj9Zi ilbo6Kx+qbatd6lOAtz9hCEN8tzct57xoox4SshzTJv3Y9DCKmSj90wjtdCByk34EjD7 SeY+VaZy8RF9KOgHrglDdQKXEG6nwpwqrbCq0Jri3JWPFMk18Gm97fyjXEoQcwrFnVI0 B6sUOM9IMfyD5ZPGqx964aTc1KbcpDL8G9rxWh4tJV4bG3ImfZd3peSDrByNC41cC6jD 1Ucg== MIME-Version: 1.0 References: <933b52ac-d372-f9d9-792e-4166f35b41f5@redhat.com> <327DC916-C1B4-47F9-92AE-468236D32C1F@oracle.com> In-Reply-To: From: Richard Biener Date: Mon, 04 Mar 2019 11:45:00 -0000 Message-ID: Subject: Re: A bug in vrp_meet? To: Qing Zhao Cc: GCC Development , Jeff Law , gcc Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00018.txt.bz2 On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote: > > > On Mar 1, 2019, at 1:25 PM, Richard Biener w= rote: > > On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao w= rote: > > Jeff, > > thanks a lot for the reply. > > this is really helpful. > > I double checked the dumped intermediate file for pass =E2=80=9Cdom3", and > located the following for _152: > > ****BEFORE the pass =E2=80=9Cdom3=E2=80=9D, there is no _152, the corresp= onding Block > looks like: > > [local count: 12992277]: > _98 =3D (int) ufcMSR_52(D); > k_105 =3D (sword) ufcMSR_52(D); > i_49 =3D _98 > 0 ? k_105 : 0; > > ***During the pass =E2=80=9Cdoms=E2=80=9D, _152 is generated as followin= g: > > Optimizing block #4 > =E2=80=A6. > 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 > > then bb 4 becomes: > > [local count: 12992277]: > _98 =3D (int) ufcMSR_52(D); > k_105 =3D _98; > _152 =3D MAX_EXPR <_98, 0>; > i_49 =3D _152; > > and all the i_49 are replaced with _152. > > However, the value range info for _152 doesnot reflect the one for > i_49, it keeps as UNDEFINED. > > is this the root problem? > > > It looks like DOM fails to visit stmts generated by simplification. Can y= ou open a bug report with a testcase? > > > The problem is, It took me quite some time in order to come up with a sma= ll and independent testcase for this problem, > a little bit change made the error disappear. > > 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? I remember running into similar issues in the past where I tried to extract temporary nonnull ranges from divisions. I have there @@ -1436,11 +1436,16 @@ dom_opt_dom_walker::before_dom_children m_avail_exprs_stack->pop_to_marker (); 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), fa= lse); + 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)); + } /* Now prepare to process dominated blocks. */ record_edge_info (bb); OTOH the issue in your case is that fold emits new stmts before gsi but the 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 b= ack to unvisited, newly inserted ones). The fold_stmt interface could in theory 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). So, does the following help? 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) itself + 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)); } /* Now prepare to process dominated blocks. */ Richard. > Thanks a lot. > > Qing > > > > Richard. > >