From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125289 invoked by alias); 1 Mar 2019 19:25:36 -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 125230 invoked by uid 89); 1 Mar 2019 19:25:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:327DC91, H*i:sk:327DC91 X-HELO: mail-wm1-f43.google.com Received: from mail-wm1-f43.google.com (HELO mail-wm1-f43.google.com) (209.85.128.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Mar 2019 19:25:32 +0000 Received: by mail-wm1-f43.google.com with SMTP id a188so6273723wmf.3; Fri, 01 Mar 2019 11:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=oXQv92TGdLowtSJ+/NG/pOuOseDihTtFsNBeY0wtiF0=; b=R+w7XyAd4K9ppw54f8BVS3ifedqfZcjsCVbpoc2UQ4Qf01sJRo77po9gLTn9TmuGQ9 fpdbBrN2e/nsFksD/bH9l3/eGIgqJszHvyrMied8Ut+Ph8zCe2ZG1n5LFifD4zURYruX MBIrFVUUrlyuaWZIxJcRPGBhtnm8j/TB+FRCfq/uqYkIM8zMdcXp9x7hFPDf6TmQkYQJ F3TkAALq1bRrmRozSj5StzJ9WwAstqoE13EqPzEHVbmNMRuxFM1YI0NRbobCos3e5w/G WPY2iSIEskNJpdc059a+8T11unWbeLGr5t7mDecrnhgGjUoPjKDktl5ecZQD3xDDJM0W Qacg== Return-Path: Received: from [192.168.178.32] (x4d075fd3.dyn.telefonica.de. [77.7.95.211]) by smtp.gmail.com with ESMTPSA id 132sm23373011wmd.27.2019.03.01.11.25.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 11:25:29 -0800 (PST) Date: Fri, 01 Mar 2019 19:25:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <327DC916-C1B4-47F9-92AE-468236D32C1F@oracle.com> References: <933b52ac-d372-f9d9-792e-4166f35b41f5@redhat.com> <327DC916-C1B4-47F9-92AE-468236D32C1F@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: A bug in vrp_meet? To: gcc@gcc.gnu.org,Qing Zhao ,Jeff Law CC: gcc Patches From: Richard Biener Message-ID: X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00005.txt.bz2 On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao wro= te: >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 correspo= nding 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 following: > >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.=20 > >However, the value range info for _152 doesnot reflect the one for >i_49, it keeps as UNDEFINED.=20 > >is this the root problem?=20=20 It looks like DOM fails to visit stmts generated by simplification. Can you= open a bug report with a testcase? Richard.=20 >thanks a lot. > >Qing > >> On Feb 28, 2019, at 1:54 PM, Jeff Law wrote: >>=20 >> On 2/28/19 10:05 AM, Qing Zhao wrote: >>> Hi, >>>=20 >>> I have been debugging a runtime error caused by value range >propagation. and finally located to the following gcc routine: >>>=20 >>> vrp_meet_1 in gcc/tree-vrp.c >>>=20 >>> =3D=3D=3D=3D >>> /* Meet operation for value ranges. Given two value ranges VR0 and >>> VR1, store in VR0 a range that contains both VR0 and VR1. This >>> may not be the smallest possible such range. */ >>>=20 >>> static void=20 >>> vrp_meet_1 (value_range *vr0, const value_range *vr1) >>> { >>> value_range saved; >>>=20 >>> if (vr0->type =3D=3D VR_UNDEFINED) >>> {=20=20=20=20 >>> set_value_range (vr0, vr1->type, vr1->min, vr1->max, >vr1->equiv); >>> return; >>> }=20=20=20=20 >>>=20 >>> if (vr1->type =3D=3D VR_UNDEFINED) >>> {=20=20=20=20 >>> /* VR0 already has the resulting range. */ >>> return; >>> }=20=20=20=20 >>> =3D=3D=3D=3D >>>=20 >>> In the above, when one of vr0 or vr1 is VR_UNDEFINED, the meet >result of these two will be the other VALUE.=20 >>>=20 >>> This seems not correct to me.=20 >> That's the optimistic nature of VRP. It's generally desired >behavior. >>=20 >>>=20 >>> For example, the following is the located incorrect value range >propagation: (portion from the dump file *.181t.dom3) >>>=20 >>> =3D=3D=3D=3D >>> Visiting PHI node: i_83 =3D PHI <_152(20), 0(22)> >>> Argument #0 (20 -> 10 executable) >>> _152: UNDEFINED >>> Argument #1 (22 -> 10 executable) >>> 0: [0, 0] >>> Meeting >>> UNDEFINED >>> and >>> [0, 0] >>> to >>> [0, 0] >>> Intersecting >>> [0, 0] >>> and >>> [0, 65535] >>> to >>> [0, 0] >>> =3D=3D=3D=3D >>>=20 >>>=20 >>> In the above, =E2=80=9Ci_83=E2=80=9D is defined as PHI <_152(20), 0(22)= >, the 1st >argument is UNDEFINED at this time(but its value range definitely is >NOT [0,0]), >>> and the 2nd argument is 0. >> If it's value is undefined then it can be any value we want. We >choose >> to make it equal to the other argument. >>=20 >> If VRP later finds that _152 changes, then it will go back and >> reevaluate the PHI. That's one of the basic design principles of the >> optimistic propagators. >>=20 >>>=20 >>> =E2=80=9Cvrp_meet=E2=80=9D generate a VR_RANGE with [0,0] for =E2=80=9C= i_83=E2=80=9D based on the >current algorithm. Obviously, this result VR_RANGE with [0,0] does NOT > >>> contain the value ranges for _152.=20 >>>=20 >>> the result of =E2=80=9Cvrp_meet=E2=80=9D is Not correct. and this inco= rrect value >range result finally caused the runtime error.=20 >>>=20 >>> I =E2=80=98d like to modify the vrp_meet_1 as following: >>>=20 >>> =3D=3D=3D=3D >>> static void=20 >>> vrp_meet_1 (value_range *vr0, const value_range *vr1) >>> { >>> value_range saved; >>>=20 >>> if (vr0->type =3D=3D VR_UNDEFINED) >>> {=20=20=20=20 >>> /* VR0 already has the resulting range. */ >>> return; >>> }=20=20=20=20 >>>=20 >>> if (vr1->type =3D=3D VR_UNDEFINED) >>> {=20=20=20=20 >>> set_value_range_to_undefined (vr0) >>> return; >>> }=20=20=20=20 >>> =3D=3D=3D=3D >>>=20 >>> let me know your opinion. >>>=20 >>> thanks a lot for the help. >> I think we (Richi and I) went through this about a year ago and the >> conclusion was we should be looking at how you're getting into the >> vrp_meet with the VR_UNDEFINED. >>=20 >> If it happens because the user's code has an undefined use, then, the >> consensus has been to go ahead and optimize it. >>=20 >> If it happens for any other reason, then it's likely a bug in GCC.=20 >We >> had a couple of these when we made EVRP a re-usable module and >started >> exploiting its data in the jump threader. >>=20 >> So you need to work backwards from this point to figure out how you >got >> here. >>=20 >> jeff