From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14954 invoked by alias); 12 Jun 2002 16:18:57 -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 14907 invoked from network); 12 Jun 2002 16:18:55 -0000 Received: from unknown (HELO www.dberlin.org) (138.88.48.165) by sources.redhat.com with SMTP; 12 Jun 2002 16:18:55 -0000 Received: by www.dberlin.org (Postfix, from userid 503) id E0E7F18000BA; Wed, 12 Jun 2002 12:18:48 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by www.dberlin.org (Postfix) with ESMTP id 3ECAF18000B9; Wed, 12 Jun 2002 12:18:43 -0400 (EDT) Date: Wed, 12 Jun 2002 09:28: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: 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/msg00801.txt.bz2 On Wed, 12 Jun 2002, Daniel Berlin wrote: > 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. By this, i meant doing it the way we are doing simplification of them, which is to pre-insert the body of the statement expression, store the return value to a temporary, replace the call_expr with the temporary. Obviously, you can't just remove the statement expression wrapper literally. > > > > Andrew. > > > > > > >