On Sat, 2015-06-20 at 01:56 +0200, Basile Starynkevitch wrote:
> Hello all,
>
> Suppose that I have some header file in C myhead.h, containing notably
>
> // Boehm's garbage collector, notably defines GC_malloc_atomic &
> GC_malloc
> #include <gc/gc.h>
> struct myintvec_st {
> unsigned vsiz; // allocated size
> unsigned vlen; // used length, always <= vsiz
> int varr[];
> };
>
> static inline struct myintvec_st*vec_alloc(unsigned siz) {
> size_t fullsiz = sizeof(struct myintvec_st)+siz*sizeof(int));
> struct myintvec_st* v = GC_malloc_atomic(fullsiz);
> memset(v, 0, fullsiz);
> v->vsiz = siz;
> return v;
> }
>
> and many other struct declaration and static inline functions and extern
> function declarations.
>
> Now, I would like to use libgccjit with a context which contains all
> the functions & structures from file myhead.h, in particular because I
> want to JIT some calls to inlined static functions, and I expect the
> gccjit to do the inlining (assuming I am using JIT with -O2 by calling
> gcc_jit_context_set_int_option with
> GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL to 2).
>
> How is that possible? What should be done to make that possible?
>
> I imagine that we might need a new function which initialize a
> gcc_jit_context from a precompiled header...
> Where should it go?
Interesting idea. I had vague plans about a using libabigail to provide
an easy way to populate a gcc_jit_context, but that wouldn't give us
inline functions, as I understand it, so PCH might be superior.
My first thought was that what you suggest *might* be possible;
something like:
extern gcc_jit_context *
gcc_jit_context_acquire_from_pch (const char *path);
where the PCH would be loaded at an appropriate place inside
toplev::main from inside gcc_jit_context_compile; see:
https://gcc.gnu.org/onlinedocs/jit/internals/index.html#overview-of-code-structure
(perhaps buffering it into memory within the call to
gcc_jit_context_acquire_from_pch and then using the buffer to
reconstruct the GC heap during compilation of the context, since the
above API suggests that "path" is accessed at the time of the call).
You would still need to lookup and refer to functions, getting a
gcc_jit_function * for them, so you'd still need to access them; maybe
we'd need a new value within enum gcc_jit_function_kind
https://gcc.gnu.org/onlinedocs/jit/topics/functions.html#gcc_jit_function_kind
to cover the "get this from inside the PCH we just loaded" use-case.
Similarly for types: we might need a way to look them up by name.
But there's at least one big issue with all this: PCH files are created
by a frontend, and libgccjit is a frontend, but it isn't cc1 or cc1plus:
are they going to be compatible? (I suspect not)
Also, do PCH files contain version metadata? It would be good to be
able to fail gracefully with an error message on a version mismatch,
rather than segfaulting.
Do we have any other serialization formats?
Would LTO be a better fit?
Dave
