From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25773 invoked by alias); 11 Feb 2014 09:55:51 -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 25763 invoked by uid 89); 11 Feb 2014 09:55:51 -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-oa0-f46.google.com Received: from mail-oa0-f46.google.com (HELO mail-oa0-f46.google.com) (209.85.219.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 11 Feb 2014 09:55:49 +0000 Received: by mail-oa0-f46.google.com with SMTP id n16so8836434oag.5 for ; Tue, 11 Feb 2014 01:55:47 -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=iIdrkrsL+T3ATVtUH/j3TG9u0n0Mobjix4s7wgEZuls=; b=Upd8rtFnCPpaCxxyY8Qh6b91Z+mF8Mzy7dgQX5OxC30ZXBVYTemXasfZ8MKYZozaMv sRmH3JZRUyKZ7GRPI9dL2zg8IVdmtX2rjFEEjIPYZWvd8PkBVSJAbtzn8wO5dSWSTizS OXCC6EnwzUGYjGs3WdobPzYiOe18vfFLJK03tYDxOyGRWNN+p4UCr6jOJtWvVCZhZ5qQ C6ewvB2d/HYI7LpgzNSG3e0GCXrz2IASC5fkOs/cIAHbEnRnPiIAcLY/w9UylQ1whajV ho8Wo234q8qh905yNV1r3KByMW5OgSDz67vxkqFsQWzUrXkfzCyIuAmkfk91xNXONvBq 2arw== X-Gm-Message-State: ALoCoQmnc9Qin9IqGVWC8ln7Y1qlOnIN/hghj0Sw2fPggGohteIyQl8ToUxOqNYj5E7UlEjOIE7f MIME-Version: 1.0 X-Received: by 10.182.230.135 with SMTP id sy7mr31357836obc.24.1392112547725; Tue, 11 Feb 2014 01:55:47 -0800 (PST) Received: by 10.76.20.175 with HTTP; Tue, 11 Feb 2014 01:55:47 -0800 (PST) In-Reply-To: <20140211022910.GA31962@atrey.karlin.mff.cuni.cz> References: <20140211022910.GA31962@atrey.karlin.mff.cuni.cz> Date: Tue, 11 Feb 2014 09:55:00 -0000 Message-ID: Subject: Re: Fwd: LLVM collaboration? From: Renato Golin To: Jan Hubicka Cc: gcc , Chandler Carruth Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00132.txt.bz2 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