Re: about header file parsing

["Marc Nieper-Wißkirchen" <marc@nieper-wisskirchen.de>]

[...]

> > Dave, would you agree to add a patch that reuses the command line
> > options set by `gcc_jit_context_add_command_line_option' when the
> > driver is invoked?
>
> It depends on the patch :)
>
> I'm not opposed on principle; gcc_jit_context_add_command_line_option
> already has the caveat:
>   "Note that only some options are likely to be meaningful"
> in the docs, and it's already something of a loophole for doing things
> that I haven't though of.
>
> I wonder if we'd need to have some distinction between options for the
> compiler vs options for the driver (maybe introduce a new entrypoint
> for driver options?).  IIRC cc1 will complain with a fatal error if it
> gets driver-specific options.

This is probably the saner approach. Having two entrypoints is
definitely no less powerful than having just one.

What do you think of gcc_jit_context_add_driver_option? Or,
alternatively, gcc_jit_context_compile_with_options and
gcc_jit_context_compile_to_file_with_options?

> > In particular, one would want to be able to
> > override `-fno-use-linker-plugin'.
> >
> > Here is a use case. Assume that jitted code wants to use <obstack.h>
> > (just to give an example). The struct obstack is opaque, and many
> > "functions" are implemented as macros. To solve the issues raised in
> > this thread, I would write a jit-obstack.c like the following:
> >
> > #include <stdalign.h>
> > #include <xalloc.h>
> > #include <obstack.h>
> >
> > #define obstack_chunk_alloc xmalloc
> > #define obstack_chunk_free free
> >
> > struct jit_obstack
> > {
> >   alignas (alignof (struct obstack)) char p[sizeof (struct obstack)];
> > };
> >
> > int
> > jit_obstack_init (struct jit_obstack *op) __attribute__ ((visibility
> > ("hidden")))
> > {
> >   return obstack_init ((struct obstack *) op);
> > }
> > ...
> >
> > The jitted code would then access obstacks solely through
> > jit-obstack.c. By doing so, we do not have to look at the internals
> > of
> > <obstack.h> (which may be different on the programmer's and the
> > target
> > system!) and we do not have to recreate opaque structures in a
> > gcc_jit_context.
> >
> > However, the code will only run as fast as C directly including
> > <obstack.h> if and only if we can use link-time optimization when
> > creating the jitted shared object through libgccjit.
>
> It sounds like you want have LTO against a "jit-obstack.so" (or
> somesuch) when the driver converts jit-generated assembler to its .so

Actually, I think I want to link against jit-obstack.o. Thus my
earlier question, whether supplying "-fuse-linker-plugin -flto
jit-obstack.o" to the driver is possible.

> This sounds really interesting; I've never tried LTO with libgccjit.
> It might just work, but I suspect you might run into unexpected issues
> of some kind.  Seems like a fun thing to experiment with.

We should do as this would allow wrapper libraries like the from the
example above and will solve many of the problems raised in this
thread.

[...]

Marc