From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7874 invoked by alias); 17 Nov 2005 01:20:26 -0000 Received: (qmail 7866 invoked by uid 22791); 17 Nov 2005 01:20:23 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 01:20:23 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jAH1J5Mj010597; Wed, 16 Nov 2005 20:19:05 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jAH1J4V07473; Wed, 16 Nov 2005 20:19:04 -0500 Received: from ballpeen.sfbay.redhat.com (ballpeen.sfbay.redhat.com [172.16.24.33]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id jAH1J1Pe013371; Wed, 16 Nov 2005 20:19:01 -0500 Received: from ballpeen.sfbay.redhat.com (ballpeen.sfbay.redhat.com [127.0.0.1]) by ballpeen.sfbay.redhat.com (8.13.4/8.13.1) with ESMTP id jAH1J0pg018041; Wed, 16 Nov 2005 17:19:00 -0800 Received: (from rth@localhost) by ballpeen.sfbay.redhat.com (8.13.4/8.13.4/Submit) id jAH1J0SQ018040; Wed, 16 Nov 2005 17:19:00 -0800 Date: Thu, 17 Nov 2005 01:20:00 -0000 From: Richard Henderson To: Mark Mitchell Cc: gcc mailing list Subject: Re: Link-time optimzation Message-ID: <20051117011900.GA17847@redhat.com> Mail-Followup-To: Richard Henderson , Mark Mitchell , gcc mailing list References: <437BB214.1070306@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437BB214.1070306@codesourcery.com> User-Agent: Mutt/1.4.2.1i 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 X-SW-Source: 2005-11/txt/msg00748.txt.bz2 On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote: > http://gcc.gnu.org/projects/lto/lto.pdf In Requirement 4, you say that the function F from input files a.o and b.o should still be named F in the output file. Why is this requirement more than simply having the debug information reflect that both names were originally F? I see you go to some length in section 3 to ensure actual symbol table duplicates, and I don't know why. The rest of the requirements look good. I cannot immediately think of anything you've forgotten. Section 2.2.1 "invalid if and of" s/and/any/ By focusing on c99 inline functions, you've forgotten the facts of gcc inline functions. I'll give you a guess as to which set of semantics are actually used in practice. Note that gcc's inline semantics are a superset of both C++ and c99, and that gcc doesn't actually implement c99 semantics at all. Section 2.2.2 You don't specifically mention arrays with differing ranges, but identical numbers of elements. E.g. 0 to 5 and 1 to 6. Section 3.4 I don't think I understand how you plan to not duplicate code from ld to locate the set of object files. The only way I can think of is for ld to actually extract the objects into new temporary files. Perhaps I've forgotten how much effort is involved here, but I can see it being easier to just duplicate this code and forget it. Section 4.1 Some more detail on what you have in mind wrt mapping scopes would be nice. My initial thought is that you wouldn't need anything special at all. Just refer to the scopes from within the IL by offset within the CIE. Perhaps I'm missing something that makes this hard. Section 4.2 What is the rationale for using a stack-based representation rather than a register-based representation? A infinite register based solution would seem to map better onto gimple, making it easier to understand the conversion into and out of. The required stacking and unstacking operations would seem to get in the way. C.f. plan9's inferno, rather than jvm or cil. I'll say that I do like the notion of emitting the type and symbol tables as normal dwarf3 output. Especially since your proposal seems to call for regular code to be emitted simultaneously, so that ld -r can work. r~