This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] an embeddable JIT-compiler based on GCC

On Thu, 3 Oct 2013, David Malcolm wrote:

> Right now all you get back from the result is a "void*" which you're
> meant to cast to machine code for the CPU.   I guess we could add an

And right now the library is calling dlopen.  Which means that although 
what the user gets is a void *, the dynamic linker processing has dealt 
with registering eh_frame information and the right hooks have been passed 
through for GDB to see that an object has been loaded and access its debug 
information.  Is this use of dlopen intended to be part of the interface, 
or just a temporary hack with users eventually needing to use other 
interfaces for eh_frame and debug info handling?  (GDB has some support 
for JITs, but I haven't looked into the details of how it works.)

> option on the gcc_jit_context for setting which ISA you want code for.

Even apart from completely separate ISAs, there's also the matter of other 
command-line options such as -march=, which I'd think users should be able 
to specify.  And the complication that default options to cc1 can be 
determined by specs, whether in .h files or from configure options such as 
--with=arch=, so cc1's defaults may not be the same as the defaults when 
you run the driver (which are likely to be better defaults for the JIT 
than cc1's).  And if the user wants to use -march=native (which seems 
sensible for the common use case of a JIT, generating code for the same 
system as runs the compiler), that's handled through specs.

Maybe the driver should be converted to library code so it's possible to 
run command-line options through it and generate the command line that 
would get passed to cc1 (but then use that to call a function in the same 
process - with a different copy of global options data, diagnostic context 
etc. to avoid any issues from those being initialized twice - rather than 
running a subprocess).  That would also allow generating the right options 
for the assembler to pass to the library version of the assembler.

> > >   * 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.
> (nods)   Note that all of the kludgery (if that's a word) is hidden
> inside the library, so we can fix it all up without affecting client
> code: the client-facing API doesn't expose any of this.
> FWIW I added timevars for measuring the invocation of the driver; that
> kludge makes up about 50% of the overall time taken.  I haven't yet
> broken that down into assembler vs linker vs fork/exec overhead, but
> clearly this is something that could use optimization - leading to
> (very) vague thoughts involving turning parts of binutils into libraries
> also.

First I guess it might simply be a library that receives blocks of text 
that currently go to asm_out_file - but eventually there might be 
efficiency to be gained by passing binary data to the assembler in some 
cases (e.g. for large blocks of debug info) rather than generating and 
then parsing text.  (So some asm_out methods would gain implementations 
passing such data instead of generating text.)

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]