From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22446 invoked by alias); 4 Jun 2008 16:34:04 -0000 Received: (qmail 22421 invoked by uid 22791); 4 Jun 2008 16:34:03 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jun 2008 16:33:38 +0000 Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id A6D182F54E7D; Wed, 4 Jun 2008 09:33:37 -0700 (PDT) Received: from relay11.apple.com (unknown [127.0.0.1]) by relay11.apple.com (Symantec Mail Security) with ESMTP id 859CE2807C; Wed, 4 Jun 2008 09:33:37 -0700 (PDT) X-AuditID: 11807130-ac395bb000000ead-77-4846c3e1bef4 Received: from [17.116.198.250] (unknown [17.116.198.250]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay11.apple.com (Apple SCV relay) with ESMTP id 217A92807B; Wed, 4 Jun 2008 09:33:37 -0700 (PDT) Cc: Diego Novillo , gcc@gcc.gnu.org, Kenneth Zadeck , Jan Hubicka , Ollie Wild , Robert Hundt Message-Id: <701D4B5D-9935-444B-973A-43A53B7C609B@apple.com> From: Chris Lattner To: Rafael Espindola In-Reply-To: <38a0d8450806040027r3794f593qfff537325963841d@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: [whopr] Design/implementation alternatives for the driver and WPA Date: Wed, 04 Jun 2008 16:34:00 -0000 References: <96A87E23-CD76-41E3-A4BD-DD399C847F17@apple.com> <38a0d8450806040027r3794f593qfff537325963841d@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg00065.txt.bz2 On Jun 4, 2008, at 12:27 AM, Rafael Espindola wrote: >> Is there a specific reason you don't use the LLVM LTO interface? >> It seems >> to be roughly the same as your proposed interface: >> >> a) it has a simple C interface like your proposed one >> b) it is already implemented in one system linker (Apple's), so GCC >> would >> just provide its own linker plugin and it would work on apple >> platforms >> c) it is richer than your interface >> d) it is battle tested, and exists today >> e) it is completely independent of llvm (by design) >> f) it is fully documented: http://llvm.org/docs/LinkTimeOptimization.html >> >> Is there something specific you don't like about the LLVM interface? > > > We are still discussing how we are going to implement, so the API is > still not final. Some things that have been pointed out: Hey Rafael! > *) Plugins could have other uses and the naming used on the LLVM LTO > interface is LTO specific. The LLVM interface uses an lto_ prefix. This interface is used by nm/ ar/etc as well as the linker. Is there something specific about lto_ that is bad? http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/lto.h?revision=HEAD&view=markup > *) We have a normal symbol table on the .o files. It is not clear if > we should assume that it will always be the case. If so, we don't need > the API part that handles that. This seems like a pretty minor point, but it would be easy to either: 1) make this an optional interface 2) make the plugin implement the symtab interfaces, but query the ELF symbol table instead of the LTO symbol table if possible. > *) How do you handle the case of multiple symbols with the same name > (say a weak and a strong one)? lto_codegen_add_must_preserve_symbol > has a char* argument. How does it know which symbol we are talking > about? The lto_symbol_attributes enum specifies linkage. > *) To save memory, one option is to have the plugin exec WPA and WPA > exec the linker again with the new objects. In this case the api > should be a bit different. That's an interesting idea, but it is very unclear to me whether it would save a significant amount of memory. Operating system VM systems are pretty good at paging out data that isn't used (e.g. the .o files the linker loaded into memory that exist when WPA is going on). -Chris