From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2539 invoked by alias); 12 Jun 2002 16:00:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2487 invoked from network); 12 Jun 2002 16:00:15 -0000 Received: from unknown (HELO www.dberlin.org) (138.88.48.165) by sources.redhat.com with SMTP; 12 Jun 2002 16:00:15 -0000 Received: by www.dberlin.org (Postfix, from userid 503) id 3DE1418000BA; Wed, 12 Jun 2002 12:00:15 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.dberlin.org (Postfix) with ESMTP id 4D672180008C; Wed, 12 Jun 2002 12:00:09 -0400 (EDT) Date: Wed, 12 Jun 2002 09:13:00 -0000 From: Daniel Berlin To: Andrew Haley Cc: Mark Mitchell , Per Bothner , Fergus Henderson , "gcc@gcc.gnu.org" , "java@gcc.gnu.org" Subject: Re: RFC: Java inliner In-Reply-To: <15623.27493.877886.644844@cuddles.cambridge.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM,AWL version=2.20 X-Spam-Level: X-SW-Source: 2002-06/txt/msg00799.txt.bz2 On Wed, 12 Jun 2002, Andrew Haley wrote: > 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. It shouldn't be all that difficult to get rid of the statement expressions. In fact, it might be the case that we can just remove the statement expression wrapper right now, and it'll still just work. i'll check. > > Andrew. > >