From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11510 invoked by alias); 20 Jan 2015 01:41:04 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 11484 invoked by uid 89); 20 Jan 2015 01:41:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.5 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Message-ID: <1421717715.4255.73.camel@surprise> Subject: Re: [PATCH] Re: Stage 3 RFC: using "jit" for ahead-of-time compilation From: David Malcolm To: Richard Biener Cc: jit@gcc.gnu.org, GCC Patches , Jakub Jelinek , Joseph Myers Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: References: <1421352359-26729-1-git-send-email-dmalcolm@redhat.com> <7ACAA3E6-6CBB-4F60-98C4-DBA0EB3C344A@gmail.com> <1421434045.4255.38.camel@surprise> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-SW-Source: 2015-q1/txt/msg00030.txt.bz2 On Mon, 2015-01-19 at 10:51 +0100, Richard Biener wrote: > On Fri, Jan 16, 2015 at 7:47 PM, David Malcolm wrote: > > On Thu, 2015-01-15 at 22:50 +0100, Richard Biener wrote: > >> On January 15, 2015 9:05:59 PM CET, David Malcolm wrote: > >> >Release managers: given that this only touches the jit, and that the > >> >jit > >> >is off by default, any objections if I go ahead and commit this? > >> >It's a late-breaking feature, but the jit as a whole is new, and > >> >I think the following is a big win, so I'd like to proceed with this in > >> >stage 3 (i.e. in the next 24 hours). There are docs and testcases. > >> > > >> >New jit API entrypoint: gcc_jit_context_compile_to_file > >> > > >> >This patch adds a way to use libgccjit for ahead-of-time compilation. > >> >I noticed that given the postprocessing steps the jit has to take to > >> >turn the .s file into in-memory code (invoke driver to convert to > >> >a .so and then dlopen), that it's not much of a leap to support > >> >compiling the .s file into objects, dynamic libraries, and executables. > >> > > >> >Doing so seems like a big win from a feature standpoint: people with > >> >pre-existing frontend code who want a backend can then plug in > >> >libgccjit > >> >and have a compiler, without needing to write it as a GCC frontend, or > >> >use LLVM. > >> > >> Note that you should make them aware of our runtime license with > >> respect to the eligible compilation process. Which means this is not > >> a way to implement proprietary front ends. > >> > >> Richard. > > > > IANAL, but as I understand things, the runtime license is an additional > > grant of rights that covers certain components of GCC that bear the GCC > > Runtime Library Exception, allowing them to be used in certain > > additional ways beyond regular GPLv3-compliance. > > > > libgccjit doesn't have that exception; it's GPLv3. > > > > Perhaps an argument could be made for libgccjit to have the exception, > > if the FSF think that that would better serve the FSF's mission; right > > now, I'm merely trying to provide a technical means to modularity. > > > > Assuming the above is correct, anything linked against it needs to be > > GPLv3-compatible. Hence any such frontend linked against libgccjit > > would need to be GPLv3-compatible. > > > > Attached is a patch (on top of the proposed one below), to clarify the > > wording in the new tutorial a little, to remind people that such linking > > needs to be license-compatible (without actually spelling out what the > > license is, though it's visible at the top of the public header file, > > libgccjit.h, as GPLv3 or later without the runtime library exception). > > > > Are the combined patches OK by you? > > Yes. > > Thanks, > Richard. Thanks. I've committed the combination of the two patches to trunk as r219876. Sorry about the lateness of this feature. With this commit, gcc now has a brainf*** frontend (albeit one hidden deep in the jit examples dir, and not using the regular frontend machinery). Dave