From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16068 invoked by alias); 11 Feb 2014 17:29:04 -0000 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 Received: (qmail 16049 invoked by uid 89); 11 Feb 2014 17:29:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f179.google.com Received: from mail-ob0-f179.google.com (HELO mail-ob0-f179.google.com) (209.85.214.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 11 Feb 2014 17:29:02 +0000 Received: by mail-ob0-f179.google.com with SMTP id wo20so9101346obc.24 for ; Tue, 11 Feb 2014 09:29:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rrkFFRr8E8XXu8ODp8Hr02aJWvjq+ayLMCzhGzaAEBk=; b=I0b9Ro4JokoiS5wf1KR/x5YIOLYqthp/jhfZxNGV3NOvzbHw+3BlcrmmY4kp/lRbyT eysS2xJldPQ0qQwRT2InPcHjhglnqQf76R9L4NgQlDIxsmlqrid7kpR8X64yGCp+DABk 4Qm7gZ5/9i06b13i2MsWiPnQqz4BkXhM1gn6XT5kC9HwtN3XwFb3HvR7sg3/UNKZAqI5 hmaECtOGCdENuArKxDEC+vu9d1rymxxqpGlR1vS9SRJVvAlFxOXrjXofE4q4r4hoB8yI JewBUNufbjT727aIPuPNnEAhdSGkTbDQUn6J/URFiXXckT2WgsEHTSEzz7CXobeKNcPs WfHg== X-Gm-Message-State: ALoCoQlHr46KOIqFuWwtzKb8w6lIpmZbGVaERwq51sKkLGq5ZJmj8xqXdgCWtXsVSMdTPstJlWja MIME-Version: 1.0 X-Received: by 10.60.84.241 with SMTP id c17mr622026oez.86.1392139740106; Tue, 11 Feb 2014 09:29:00 -0800 (PST) Received: by 10.76.20.175 with HTTP; Tue, 11 Feb 2014 09:28:59 -0800 (PST) In-Reply-To: References: <20140211022910.GA31962@atrey.karlin.mff.cuni.cz> Date: Tue, 11 Feb 2014 17:29:00 -0000 Message-ID: Subject: Re: Fwd: LLVM collaboration? From: Renato Golin To: Jan Hubicka Cc: gcc , =?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?= Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00140.txt.bz2 Now copying Rafael, which can give us some more insight on the LLVM LTO side. cheers, --renato On 11 February 2014 09:55, Renato Golin wrote: > Hi Jan, > > I think this is a very good example where we could all collaborate > (including binutils). > > I'll leave your reply intact, so that Chandler (CC'd) can get a bit > more context. I'm copying him because he (and I believe Diego) had > more contact with LTO than I had. > > If I got it right, LTO today: > > - needs the drivers to explicitly declare the plugin > - needs the library available somewhere > - may have to change the library loading semantics (via LD_PRELOAD) > > Since both toolchains do the magic, binutils has no incentive to > create any automatic detection of objects. > > The part that I didn't get is when you say about backward > compatibility. Would LTO work on a newer binutils with the liblto but > on an older compiler that knew nothing about LTO? > > Your proposal is, then, to get binutils: > > - recognizing LTO logic in the objects > - automatically loading liblto if recognized > - warning if not > > I'm assuming the extra symbols would be discarded if no library is > found, together with the warning, right? Maybe an error if -Wall or > whatever. > > Can we get someone from the binutils community to opine on that? > > cheers, > --renato > > On 11 February 2014 02:29, Jan Hubicka wrote: >> One practical experience I have with LLVM developers is sharing experiences >> about getting Firefox to work with LTO with Rafael Espindola and I think it was >> useful for both of us. I am definitly open to more discussion. >> >> Lets try a specific topic that is on my TODO list for some time. >> >> I would like to make it possible for mutliple compilers to be used to LTO a >> single binary. As we are all making LTO more useful, I think it is matter of >> time until people will start shipping LTO object files by default and users >> will end up feeding them into different compilers or incompatible version of >> the same compiler. We probably want to make this work, even thought the >> cross-module optimization will not happen in this case. >> >> The plugin interface in binutils seems to do its job well both for GCC and LLVM >> and I hope that open64 and ICC will eventually join, too. >> >> The trouble however is that one needs to pass explicit --plugin argument >> specifying the particular plugin to load and so GCC ships with its own wrappers >> (gcc-nm/gcc-ld/gcc-ar and the gcc driver itself) while LLVM does similar thing. >> >> It may be smoother if binutils was able to load multiple plugins at once and >> grab plugins from system and user installed compilers without explicit --plugin >> argument. >> >> Binutils probably should also have a way to detect LTO object files and produce >> more useful diagnostic than they do now, when there is no plugin claiming them. >> >> There are some PRs filled on the topic >> http://cygwin.com/frysk/bugzilla/show_bug.cgi?id=15300 >> http://cygwin.com/frysk/bugzilla/show_bug.cgi?id=13227 >> but not much progress on them. >> >> I wonder if we can get this designed and implemented. >> >> On the other hand, GCC current maintains non-plugin path for LTO that is now >> only used by darwin port due to lack of plugin enabled LD there. It seems >> that liblto used by darwin is losely compatible with the plugin API, but it makes >> it harder to have different compilers share it (one has to LD_PRELOAD liblto >> to different one prior executing the linker?) >> >> I wonder, is there chance to implement linker plugin API to libLTO glue or add >> plugin support to native Darwin tools? >> >> Honza