From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1327 invoked by alias); 18 Jul 2014 05:06:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 1258 invoked by uid 89); 18 Jul 2014 05:06:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,DATE_IN_PAST_12_24,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 18 Jul 2014 05:06:10 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6I569xQ005704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 18 Jul 2014 01:06:09 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-61.phx2.redhat.com [10.3.113.61]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6I55vrs031991; Fri, 18 Jul 2014 01:06:07 -0400 Message-ID: <53C78B54.8080809@redhat.com> Date: Fri, 18 Jul 2014 05:06:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Richard Biener CC: gcc-patches Subject: Re: [tree-optimization/61607] Look through SSA_NAME_VALUE chains References: <53B10A08.4000306@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg01258.txt.bz2 On 07/07/14 03:02, Richard Biener wrote: > On Mon, Jun 30, 2014 at 8:56 AM, Jeff Law wrote: >> >> SSA_NAME_VALUE is, in effect, a chain of values. ie, it's possible for >> SSA_NAME_VALUE of any given SSA_NAME to refer to another SSA_NAME. > > Hmm, but it shouldn't .... as we walk in dominator order and should > always do set_ssa_name_value (name, ssa_name_value (value)) > there shouldn't be any chains. They're certainly there and always have been. You can get chains in cases where we derive implicit sets, for example as well as due to loops in the CFG. > > But maybe I'm missing sth about the lattice used by DOM here ... > (at least none of the callers in DOM care to valueize 'value' before > setting it as value for an SSA name). It's not really a lattice in the way you'd see in VRP. It's just an equality relationship with an unwinding stack to allow us to restore state from earlier points in the domwalk. jeff