From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8828 invoked by alias); 22 Oct 2004 21:14:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 8820 invoked from network); 22 Oct 2004 21:14:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 22 Oct 2004 21:14:50 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id i9MLEjrg019486; Fri, 22 Oct 2004 17:14:45 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9MLEjr05715; Fri, 22 Oct 2004 17:14:45 -0400 Received: from pain (vpn50-70.rdu.redhat.com [172.16.50.70]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id i9MLEfvn032085; Fri, 22 Oct 2004 17:14:42 -0400 Subject: Re: [ssaupdate] Local dominance info From: Andrew MacLeod To: Zdenek Dvorak Cc: Michael Matz , gcc-patches In-Reply-To: <20041022210841.GB1486@atrey.karlin.mff.cuni.cz> References: <20041019215129.GA29721@atrey.karlin.mff.cuni.cz> <1098279112.5695.3918.camel@pain> <20041020192719.GA20919@atrey.karlin.mff.cuni.cz> <1098310966.20227.24.camel@pain> <1098463105.20227.52.camel@pain> <20041022210841.GB1486@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Message-Id: <1098479679.20227.68.camel@pain> Mime-Version: 1.0 Date: Fri, 22 Oct 2004 21:47:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg01964.txt.bz2 On Fri, 2004-10-22 at 17:08, Zdenek Dvorak wrote: > Hello, > > > > So far all Ive seen/heard is keeping the information up to date doesnt > > cost a lot, but I see few passes have a use for it. Tell me how useful > > it is, and why its better than calculating it on the fly when you need > > it and maybe I am convinced. > > answer to your questions from my side is "I don't know." I think it > will be useful (obviously :-), but it may turn out that I will be wrong. > Ssaupdate is a development branch, so the way things are done now do not > necessarily have to be the same (or even close to) those that will be in > final version. Fair enough :-). I was just watching changes early :-) Andrew