Re: [PATCH] Re: Stage 3 RFC: using "jit" for ahead-of-time compilation

[David Malcolm <dmalcolm@redhat.com>]

On Mon, 2015-01-19 at 10:51 +0100, Richard Biener wrote:
> On Fri, Jan 16, 2015 at 7:47 PM, David Malcolm <dmalcolm@redhat.com> wrote:
> > On Thu, 2015-01-15 at 22:50 +0100, Richard Biener wrote:
> >> On January 15, 2015 9:05:59 PM CET, David Malcolm <dmalcolm@redhat.com> 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