From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3104 invoked by alias); 5 Mar 2019 21:17: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 3077 invoked by uid 89); 5 Mar 2019 21:17:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Mar 2019 21:17:16 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B2187C0495A1; Tue, 5 Mar 2019 21:17:14 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-13.rdu2.redhat.com [10.10.112.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id DF4E6600D7; Tue, 5 Mar 2019 21:17:13 +0000 (UTC) Subject: Re: A bug in vrp_meet? To: Qing Zhao Cc: gcc@gcc.gnu.org, gcc Patches References: <933b52ac-d372-f9d9-792e-4166f35b41f5@redhat.com> <327DC916-C1B4-47F9-92AE-468236D32C1F@oracle.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <869e5928-d6bd-721d-8b14-5a31fff0ef93@redhat.com> Date: Tue, 05 Mar 2019 21:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <327DC916-C1B4-47F9-92AE-468236D32C1F@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00036.txt.bz2 On 3/1/19 10:49 AM, Qing Zhao wrote: > Jeff, > > thanks a lot for the reply. > > this is really helpful. > > I double checked the dumped intermediate file for pass “dom3", and > located the following for _152: > > ****BEFORE the pass “dom3”, there is no _152, the corresponding Block > looks like: > >   [local count: 12992277]: >   _98 = (int) ufcMSR_52(D); >   k_105 = (sword) ufcMSR_52(D); >   i_49 = _98 > 0 ? k_105 : 0; > > ***During the pass “doms”,  _152 is generated as following: > > Optimizing block #4 > …. > Visiting statement: > i_49 = _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 = _98 > 0 ? k_105 : 0; >   Replaced 'k_105' with variable '_98' > gimple_simplified to _152 = MAX_EXPR <_98, 0>; > i_49 = _152; >   Folded to: i_49 = _152; > LKUP STMT i_49 = _152 > ==== ASGN i_49 = _152 > > then bb 4 becomes: > >   [local count: 12992277]: >   _98 = (int) ufcMSR_52(D); >   k_105 = _98; >   _152 = MAX_EXPR <_98, 0>; >   i_49 = _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?   Yes, I think so. It's like we didn't record anything for _152 when we simplified the RHS to a MAX_EXPR. Jeff