From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-69785-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 25153 invoked by alias); 5 Mar 2003 23:09:02 -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 25145 invoked from network); 5 Mar 2003 23:09:02 -0000
Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106)
  by 172.16.49.205 with SMTP; 5 Mar 2003 23:09:02 -0000
Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107])
	by nikam.ms.mff.cuni.cz (Postfix) with SMTP
	id 329C84DECF; Thu,  6 Mar 2003 00:09:03 +0100 (CET)
Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Thu, 6 Mar 2003 00:09:05 +0100
Date: Thu, 06 Mar 2003 00:49:00 -0000
From: Jan Hubicka <jh@suse.cz>
To: Mark Mitchell <mark@codesourcery.com>
Cc: Jan Hubicka <jh@suse.cz>, Devang Patel <dpatel@apple.com>,
	Richard Henderson <rth@redhat.com>, snyder <snyder@fnal.gov>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Implementing unit-at-a-time for C++
Message-ID: <20030305230905.GE3711@kam.mff.cuni.cz>
References: <20030305173330.GE18675@kam.mff.cuni.cz> <288940000.1046886814@warlock.codesourcery.com> <20030305221443.GB3711@kam.mff.cuni.cz> <1046905679.28834.26.camel@doubledemon.codesourcery.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1046905679.28834.26.camel@doubledemon.codesourcery.com>
User-Agent: Mutt/1.3.28i
X-SW-Source: 2003-03/txt/msg00368.txt.bz2

> 
> > > The current scheme allows us to avoid presenting the back end with the body
> > > of f<int> in this case:
> > > 
> > >  g() { if (0) f<int>(); }
> > 
> > How does the tree representation of this call look like?  Is that
> > ordinary FUNCTION_DECL?
> 
> Yes, it's just a CALL_EXPR with a FUNCTION_DECL under it.
> 
> > > When the tree optimization stuff is working, we could presumably go to 
> > > unit-at-a-time, and get the same results.  Until the optimization is 
> > > working, we'd end up thinking that the body of f<int> is needed.
> > I guess this is not that major problem.  Hope that tree optimizers will
> > enter the game soon.
> 
> But I think that it's inappropriate to make your changes (or at least
> enable them by default) until it happens.

OK, I will try to implement them and not enable by default then and lets
see how the code will look like.

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com