This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] libgccjit.so: an embeddable JIT-compiler based on GCC
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 3 Oct 2013 21:42:45 +0000
- Subject: Re: [PATCH] libgccjit.so: an embeddable JIT-compiler based on GCC
- Authentication-results: sourceware.org; auth=none
- References: <1380763968 dot 3628 dot 47 dot camel at surprise>
On Wed, 2 Oct 2013, David Malcolm wrote:
> The idea is that GCC is configured with a special --enable-host-shared
> option, which leads to it being built as position-independent code. You
> would configure it with host==target, given that the generated machine
> code will be executed within the same process (the whole point of JIT).
Configuring with a different target also makes sense - consider JIT
generation of code for a GPU (for example). (Of course lots of other
cleanups would be needed to be able to generate code for multiple targets
within the same process / same copy of libgccjit.so, but the idea seems
useful. There are probably tricks available involving building multiple
copies with different SONAMEs / symbol names. Anyway, it may make sense
now to consider defining the interfaces in a way that would support
choosing the target for which you get a context.)
> * There are some grotesque kludges in internal-api.c, especially in
> how we go from .s assembler files to a DSO (grep for "gross hack" ;) )
Apart from making the assembler into a shared library itself, it would
also be nice to avoid needing those files at all (via an API for writing
assembler text that doesn't depend on a FILE * pointer, although on GNU
hosts you can always use in-memory files via open_memstream, which would
make the internal changes much smaller). But in the absence of such a
cleanup, running the assembler via the driver should work, although
inefficient.
What do you do about errors and warnings (other than hope that they don't
get generated)? Again, one step is to avoid anything that directly uses
stderr / stdout (explicitly, or implicitly through functions such as
printf), so allowing FILE * pointers to instead be something opened with
open_memstream, while a larger cleanup would narrow the interface to
writing such text as far as possible (to well-defined diagnostic and
dumping interfaces that don't directly take a FILE *, eliminating all ad
hoc calls to fprintf etc.).
--
Joseph S. Myers
joseph@codesourcery.com