Re: about header file parsing

[David Malcolm <dmalcolm@redhat.com>]

On Thu, 2019-01-10 at 13:46 +0100, Marc Nieper-Wißkirchen wrote:
> Am Do., 10. Jan. 2019 um 09:21 Uhr schrieb Marc Nieper-Wißkirchen
> <marc@nieper-wisskirchen.de>:
> > 
> > Am Di., 8. Jan. 2019 um 22:16 Uhr schrieb Basile Starynkevitch
> > <basile@starynkevitch.net>:
> > 
> > [...]
> > 
> > > Still another thing could be to use LTO: you'll compile your C
> > > file with
> > > GCC using -flto, you'll do LIBGCCJIT things, and the final
> > > executable
> > > sould be compiled and linked with -flto.
> > 
> > Is using:
> > 
> > gcc_jit_context_add_command_line_option (ctxt, "-flto helper.o");
> > 
> > supported to have the object generated by libgccjit statically
> > linked
> > with the object helper.o before libgccjit emits the final dynamic
> > library? (Let's assume that helper.o has been compiled with -flto.)
> 
> [...]
> 
> Having taken a look at the source code of libgccjit, it seems that
> the
> command line options set by `gcc_jit_context_add_command_line_option'
> are not passed to the driver used to compile the generated 'fake.s':
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/jit/jit-playback.c?view=mar
> kup#l2407

I think so.  They're used by playback::context::compile's
make_fake_args and thus used by the in-process compile, but they're
not used by invoke_driver for the conversion from assembler to shared
library.

I can't remember if that's a deliberate omission, or if an oversight on
my part.

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

> 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

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.

Dave