From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-54932-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22457 invoked by alias); 12 Jun 2002 15:40:34 -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 22425 invoked from network); 12 Jun 2002 15:40:29 -0000
Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237)
  by sources.redhat.com with SMTP; 12 Jun 2002 15:40:29 -0000
Received: from cuddles.cambridge.redhat.com (vpn50-1.rdu.redhat.com [172.16.50.1])
	by executor.cambridge.redhat.com (Postfix) with ESMTP
	id 49A33ABAFC; Wed, 12 Jun 2002 16:40:23 +0100 (BST)
Received: (from aph@localhost)
	by cuddles.cambridge.redhat.com (8.11.6/8.11.0) id g5CFeLS20059;
	Wed, 12 Jun 2002 16:40:21 +0100
X-Authentication-Warning: cuddles.cambridge.redhat.com: aph set sender to aph@cambridge.redhat.com using -f
From: Andrew Haley <aph@cambridge.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15623.27493.877886.644844@cuddles.cambridge.redhat.com>
Date: Wed, 12 Jun 2002 08:45:00 -0000
To: Mark Mitchell <mark@codesourcery.com>
Cc: Per Bothner <per@bothner.com>,
	Fergus Henderson <fjh@cs.mu.OZ.AU>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	"java@gcc.gnu.org" <java@gcc.gnu.org>
Subject: Re: RFC: Java inliner
In-Reply-To: <5620000.1023887664@warlock.codesourcery.com>
References: <3D07096A.5010102@bothner.com>
	<5620000.1023887664@warlock.codesourcery.com>
X-SW-Source: 2002-06/txt/msg00797.txt.bz2

Mark Mitchell writes:
 > 
 > 
 > > I believe the right thing to do in the short term is extend the C/C++
 > > inliner to understand the Java trees.  Almost all of the tree codes
 > > encountered will be generic tree codes defined in tree.def.
 > 
 > If that is true -- and if languages other than Java are actually using
 > these tree codes -- that is fine.
 > 
 > The current inliner already has mechanisms for language-specific
 > extensions.  If those can be used, or it can be easily extended so that
 > they can be used, great.

Okay.

 > The contention was that the current inliner could *not* be used, and that
 > an entirely new one had to be written.

Not exactly, although some of the structures used in the inliner
(e.g. statement expressions) aren't going to make my life very easy.

Andrew.