From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-106496-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 3640 invoked by alias); 13 Dec 2004 16:38:18 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 3614 invoked from network); 13 Dec 2004 16:38:10 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sourceware.org with SMTP; 13 Dec 2004 16:38:10 -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 iBDGc0q9010002;
	Mon, 13 Dec 2004 11:38:05 -0500
Received: from vpn50-67.rdu.redhat.com (vpn50-67.rdu.redhat.com [172.16.50.67])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iBDGbxr07212;
	Mon, 13 Dec 2004 11:37:59 -0500
Subject: Re: Good news about increased jump threading from my PHI merge
	patch
From: Jeffrey A Law <law@redhat.com>
Reply-To: law@redhat.com
To: Kazu Hirata <kazu@cs.umass.edu>
Cc: gcc@gcc.gnu.org, stevenb@suse.de, dvorakz@suse.cz
In-Reply-To: <20041211.022458.119878301.kazu@cs.umass.edu>
References: <20041211.022458.119878301.kazu@cs.umass.edu>
Content-Type: text/plain
Organization: Red Hat, Inc
Date: Mon, 13 Dec 2004 16:38:00 -0000
Message-Id: <1102955877.14666.94.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-12/txt/msg00458.txt.bz2

On Sat, 2004-12-11 at 02:24 -0500, Kazu Hirata wrote:
> Hi,
> 
> I was playing with my PHI merge patch that merge two PHI nodes like
> 
>   # tem_6 = PHI <tem_17(8), tem_23(7)>;
> <L9>:;
> 
>   # tem_3 = PHI <tem_6(9), tem_2(5)>;
> <L10>:;
> 
> into one PHI node like so
> 
>   # tem_3 = PHI <tem_23(7), tem_2(5), tem_17(8)>;
> <L10>:;
> 
> I've been saying my PHI merge patch would improve jump threading but
> never said by how much.  So here is that number.
[ ... ]
Thanks.  It's still on my list of things to evaluate for 4.0, mostly
because of its potential to help compile-times on some of our 
problematical cases without introducing lots of regressions elsewhere.

You mentioned that we can't handle large PHI nodes.  Can you comment
more on that -- that would be my largest individual concern right now.

jeff