From: "Marc Nieper-Wißkirchen" <marc@nieper-wisskirchen.de>
To: Basile Starynkevitch <basile@starynkevitch.net>
Cc: akrl <akrl@sdf.org>,
jit@gcc.gnu.org, David Malcolm <dmalcolm@redhat.com>
Subject: Re: about header file parsing
Date: Tue, 01 Jan 2019 00:00:00 -0000 [thread overview]
Message-ID: <CAEYrNrS0MREt68gab2DHzOTwHk9uEMjpOeUXccjOuq1nZvid8w@mail.gmail.com> (raw)
In-Reply-To: <CAEYrNrSTSAb8H5hgop-w0Fte7TDZCY0zBCBkhBy3p-pNBc9rDA@mail.gmail.com>
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=markup#l2407
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? 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.
-- Marc
next prev parent reply other threads:[~2019-01-10 12:46 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-01 0:00 akrl
2019-01-01 0:00 ` Basile Starynkevitch
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2019-01-01 0:00 ` Marc Nieper-Wißkirchen [this message]
2019-01-01 0:00 ` David Malcolm
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2019-01-01 0:00 ` David Malcolm
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` David Malcolm
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2019-01-01 0:00 ` David Malcolm
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` David Malcolm
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` David Malcolm
2019-01-01 0:00 ` Basile Starynkevitch
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` Basile Starynkevitch
2019-01-01 0:00 ` David Malcolm
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2019-01-01 0:00 ` Basile Starynkevitch
2019-01-01 0:00 ` akrl
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
2019-01-01 0:00 ` David Malcolm
[not found] <df8944b7-1fbe-b56f-cc48-ab926d0cb5ad@starynkevitch.net>
2019-01-01 0:00 ` Basile Starynkevitch
2019-01-01 0:00 ` Marc Nieper-Wißkirchen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEYrNrS0MREt68gab2DHzOTwHk9uEMjpOeUXccjOuq1nZvid8w@mail.gmail.com \
--to=marc@nieper-wisskirchen.de \
--cc=akrl@sdf.org \
--cc=basile@starynkevitch.net \
--cc=dmalcolm@redhat.com \
--cc=jit@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).