Re: about header file parsing

[David Malcolm <dmalcolm@redhat.com>]

On Wed, 2019-01-09 at 15:04 +0100, Basile Starynkevitch wrote:
> On 1/9/19 12:12 PM, akrl wrote:
> > 
> > I think the idea of having something like a gcc plugin that once is
> > parsed
> > compiles the subset of supported C to the necessary libgccjit code
> > would be
> > useful to have for this cases but also educative for learning how
> > to use the
> > library.
> > 
> > Would be this something that is upstreamable in some form?
> > 
> 
> I don't know of any GCC plugin within the GCC code base (except the
> test cases for plugins).

I think GCC's one-year release would be too slow for such a plugin, so
I think it would best to keep it out-of-tree, at least initially.

> And I am not sure it would be that easy. If I understand well,
> what you suggest would either fill some gcc_jit_context, or create it
> already filled with an API.
> 
> But, AFAIK, there is no current way to query the content of some
> gcc_jit_context. In other words, it
> seems (but I could be wrong) that what is lacking is an API to e.g.
> *fetch* all the struct-ures and
> all the functions inside a gcc_jit_context, and we don't have that
> yet.

Interesting idea, and one that somehow I didn't think of; thanks.

I don't know that client code wants to fetch *all* entities; maybe we
want something like:

extern gcc_jit_type *
gcc_jit_context_get_type_by_name (gcc_jit_context *, const char *);

extern gcc_jit_field *
gcc_jit_type_get_field_by_name (gcc_jit_type *, const char *);

...and so on.  But I'm thinking of this from the "write a JIT for
CPython" use-case, whereas IIRC you're on the functional programming
side of the family.

I think the above would be perfectly implementable, and probably make
it much easier to implement things.

I suppose we could have a:

extern gcc_jit_object *
gcc_jit_context_for_each_object (gcc_jit_context *,
                                 some_callback_type,
                                 void *user_data,
                                 int visit_parent_contexts);

or somesuch, though I don't know if we have enough introspection in the
API yet for this to be useful.

> Or perhaps, I have misundertood your idea.
> 
> My feeling was that the GCC plugin would fill whatever data structure
> is used by the application using libgccjit.
> And that is application specific -so the GCC plugin has to be
> application specific too.

I don't think it has to be; I think the plugin just needs to emit some
kind of reflected representation of the IR of interest in some form
that can populate a gcc_jit_context.

> Cheers
> 
> PS. I could be very wrong, it is not clear in my head!

Thanks

Dave