GCCJIT guidelines (for JITing with existing types and structures)

GCCJIT guidelines (for JITing with existing types and structures)

[Basile Starynkevitch]

Hello All,

I am a bit confused about how practically should GCCJIT be used to generate code
for some existing library.

(My real case is the MELT monitor I am working on, but I will take a
more realistic example: GUILE).

Imagine someone want to use GCCJIT to add some just-in-time
compilation ability for GUILE (or even Ocaml bytecode).

GUILE has dozens (or perhaps hundreds, I did not count them) of C
struct-ures describing the internal data layout of GUILE
data structures and valus.

For many of those data structures, accessing some internal data
quickly is essential for performance. 

In particular, GUILE has vectors, and C people extending GUILE would
use the following macros to access them:

/// macros from libguile/vectors.h

/* Fast, non-checking accessors for simple vectors.
 */
#define SCM_SIMPLE_VECTOR_LENGTH(x)      SCM_I_VECTOR_LENGTH(x)
#define SCM_SIMPLE_VECTOR_REF(x,idx)     ((SCM_I_VECTOR_ELTS(x))[idx])
#define SCM_SIMPLE_VECTOR_SET(x,idx,val) ((SCM_I_VECTOR_WELTS(x))[idx]=(val))


/* Internals */

#define SCM_I_IS_VECTOR(x)     (SCM_HAS_TYP7 (x, scm_tc7_vector))
#define SCM_I_VECTOR_ELTS(x)   ((const SCM *) SCM_I_VECTOR_WELTS (x))
#define SCM_I_VECTOR_WELTS(x)  (SCM_CELL_OBJECT_LOC (x, 1))
#define SCM_I_VECTOR_LENGTH(x) (((size_t) SCM_CELL_WORD_0 (x)) >> 8)

/// macros from libguile/gc.h
#define SCM_GC_CELL_OBJECT(x, n) (((SCM *)SCM2PTR (x)) [n])
#define SCM_GC_CELL_WORD(x, n)   (SCM_UNPACK (SCM_GC_CELL_OBJECT ((x), (n))))
#define SCM_CELL_WORD_0(x) SCM_CELL_WORD ((x), 0)
#define SCM_CELL_OBJECT_LOC(x, n) (SCM_VALIDATE_CELL((x), &SCM_GC_CELL_OBJECT ((x), (n))))
#define SCM_CELL_WORD(x, n) \
  SCM_VALIDATE_CELL ((x), SCM_GC_CELL_WORD ((x), (n)))


In the OCAML world, you have similar things. 
Some structures and lots of macrso in its <caml/mlvalues.h>


In all cases, the target infrastructure is defining a big lot of
struct (and often, macro accessing them) in its header file.

If I understand correctly, there is today no automatic way to redefine
these structures and fields and inlined accessors (either as inlined
functions or macros) for GCCJIT.

Any JIT effort for some existing thing cannot systematically use
non-inlined functions to access content inside values (because a call
to such a function simply to extract the N-th element of some internal
array in a struct would ruin performance).

So what is the roadmap for such issues? We might have some way to
start a GCCJIT context from some compiled GCC header, of after having
parsed some C or C++ file, but we don't have that yet. Or we could
have some option for LTO... Or we could perhaps consider adding a
plugin to GCC which would handle specific attributes or pragmas to
dump some C code initializing a GCCJIT context....

In other words, what is the bridge between an existing code base
(e.g. of some interpreter its bytecode VM) and GCCJIT?

How have people already using GCCJIT dealt with such an issue?

Regards
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net   mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: GCCJIT guidelines (for JITing with existing types and structures)

[Dibyendu Majumdar]

Hi Basile,

On 13 October 2015 at 10:12, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> I am a bit confused about how practically should GCCJIT be used to generate code
> for some existing library.
>
> Imagine someone want to use GCCJIT to add some just-in-time
> compilation ability for GUILE (or even Ocaml bytecode).
>
> GUILE has dozens (or perhaps hundreds, I did not count them) of C
> struct-ures describing the internal data layout of GUILE
> data structures and valus.
>
> For many of those data structures, accessing some internal data
> quickly is essential for performance.
>
> In other words, what is the bridge between an existing code base
> (e.g. of some interpreter its bytecode VM) and GCCJIT?
>
> How have people already using GCCJIT dealt with such an issue?
>

In Ravi I have manually coded the type definitions for all the Lua
structs that I need to access.

Regards