From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21986 invoked by alias); 11 Feb 2014 02:29:18 -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 21972 invoked by uid 89); 11 Feb 2014 02:29:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: atrey.karlin.mff.cuni.cz Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Feb 2014 02:29:13 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 86139818A7; Tue, 11 Feb 2014 03:29:10 +0100 (CET) Date: Tue, 11 Feb 2014 02:29:00 -0000 From: Jan Hubicka To: Renato Golin Cc: gcc@gcc.gnu.org Subject: Re: Fwd: LLVM collaboration? Message-ID: <20140211022910.GA31962@atrey.karlin.mff.cuni.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00128.txt.bz2 > 1. There IS an unnecessary fence between GCC and LLVM. > > License arguments are one reason why we can't share code as easily as > we would like, but there is no argument against sharing ideas, > cross-reporting bugs, helping each other implement a better > compiler/linker/assembler/libraries just because of an artificial > wall. We need to break this wall. > > I rarely see GCC folks reporting bugs on our side, or people saying > "we should check with the GCC folks" actually doing it. We're not > contagious folks, you know. Talking to GCC engineers won't make me a > lesser LLVM engineer, and vice-versa. 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