From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7395 invoked by alias); 21 Jul 2002 14:22:31 -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 7388 invoked from network); 21 Jul 2002 14:22:31 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by sources.redhat.com with SMTP; 21 Jul 2002 14:22:31 -0000 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id BDCD314798; Sun, 21 Jul 2002 16:22:30 +0200 (MEST) Received: from aj by arthur.inka.de with local (Exim 3.34 #1) id 17WHbQ-00088v-00; Sun, 21 Jul 2002 16:22:28 +0200 Mail-Copies-To: never To: Pop Sébastian Cc: Jason Merrill , Richard Henderson , Per Bothner , Diego Novillo , Mark Mitchell , gcc@gcc.gnu.org Subject: Re: Language-independent functions-as-trees representation References: <20020721140611.GA17810@gauvain.u-strasbg.fr> From: Andreas Jaeger Date: Sun, 21 Jul 2002 11:44:00 -0000 In-Reply-To: <20020721140611.GA17810@gauvain.u-strasbg.fr> (Pop Sébastian's message of "Sun, 21 Jul 2002 16:06:11 +0200") Message-ID: User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2002-07/txt/msg00952.txt.bz2 Pop Sébastian writes: > On Sun, Jul 21, 2002 at 08:42:43AM +0200, Andreas Jaeger wrote: >> Jason Merrill writes: >> >> > In a previous thread, Diego has suggested that inlining would be done on >> > language-dependent trees. I think this is a mistake; IMO it should be done >> > at the SIMPLE level. Requiring the inliner to know about frontend trees is >> > wrong. >> >> Inlining on SIMPLE might also allow to inline mixed languages, e.g. C >> code into Fortran. > > This would require to store SIMPLE trees comming from different front-ends > then reconstruct a global tree. > (a little as the SGI's compiler works for interprocedural analysis, storing > WHIRL trees into .o files, then building the whole tree at link/optimize time). It would only make sense with whole program optimizations for interprocedural analysis. Currently GCC does not do anything of this kind but we should think forward and whole program optimizations is something that some of us might want to see. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj