From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3922 invoked by alias); 12 Jun 2002 13:15:59 -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 3851 invoked from network); 12 Jun 2002 13:15:53 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 12 Jun 2002 13:15:53 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g5CDEP901973; Wed, 12 Jun 2002 06:14:25 -0700 Date: Wed, 12 Jun 2002 06:38:00 -0000 From: Mark Mitchell To: Per Bothner cc: Andrew Haley , Fergus Henderson , "gcc@gcc.gnu.org" , "java@gcc.gnu.org" Subject: Re: RFC: Java inliner Message-ID: <5620000.1023887664@warlock.codesourcery.com> In-Reply-To: <3D07096A.5010102@bothner.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-06/txt/msg00788.txt.bz2 --On Wednesday, June 12, 2002 01:42:18 AM -0700 Per Bothner wrote: > Mark Mitchell wrote: >> The right thing to do is clear: convert the Java front end to use trees >> that are more like the C/C++ trees. > > Let us recap: I deliberately tried to avoid reopening this issue. The whole IF_STMT vs. COND_EXPR debate isn't relevant at this point. We are where we are. We could have the argument about *why* we are here again -- but I don't think anybody cares. Lots of people (including me) think the C/C++ representation is better; at least some people (including you) think the Java representation is better. That's OK. Reopening that -- and adding fuel to the fire by talking about who did what to whom -- just isn't productive. > 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. The contention was that the current inliner could *not* be used, and that an entirely new one had to be written. It would be better to change the Java front end as necessary to make the current inliner usable than to write a new one. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com