Re: about header file parsing

[David Malcolm <dmalcolm@redhat.com>]

On Thu, 2019-01-10 at 19:23 +0100, Marc Nieper-Wißkirchen wrote:
> [...]
> 
> > > 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?

I prefer gcc_jit_context_add_driver_option.

> > > 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.

Aha.  Makes sense.  I think this would be three invocations of
gcc_jit_context_add_driver_option, one per option.

> > 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.

Indeed (assuming no unexpected snags...)

Dave