From: Basile Starynkevitch <basile@starynkevitch.net>
To: "Marc Nieper-Wißkirchen" <marc@nieper-wisskirchen.de>, jit@gcc.gnu.org
Subject: Re: Incremental compilation
Date: Mon, 01 Jan 2018 00:00:00 -0000 [thread overview]
Message-ID: <1bc5aeb1-d251-0335-6103-eba3f6258456@starynkevitch.net> (raw)
In-Reply-To: <CAEYrNrQmfhLZVJZdPo1pJt9nXdxx0Vttcqc5kwJR8dt8gasPEA@mail.gmail.com>
On 12/29/18 4:31 PM, Marc Nieper-WiÃkirchen wrote:
> Hi!
I am guessing that you use libgccjit on Linux.
>
> I need to compile a number of functions incrementally. Eventually, I
> would like to compile all the functions to a dynamic library file.
Notice that, if you are compiling each function incrementally, it has to
be some exported function (GCC_JIT_FUNCTION_EXPORTED), otherwise you
won't see it between your different compilations.
>
> Can this be achieved with libgccjit without recompiling the functions?
Probably not, and I don't understand why you need that in practice.
The common wisdom would be to compile each function separately (perhaps
into its own shared object on Linux).
Be aware that it is perfectly acceptable to have a big lot (e.g. many
hundred thousands) of shared objects on Linux.
My manydl.c program (which does not use libgccjit) on
https://github.com/bstarynk/misc-basile/blob/master/manydl.c is
generating some C code, compiling it as a plugin, and dlopen-ing it. ItÂ
can repeat that a lot of times.
The only caveat when compiling small functions separately is that you
have to spend one (or a few) pages (of 4Kbytes) on every compilation,
since the result of a compilation fits in a separate page (e.g. in
different *.so files). So if the function is tiny and takes only a
hundred byte, you lose some virtual address space. In practice, that is
no much a problem (at least on x86-64 under Linux).
My guess is that you are sort-of implementing some Read Eval Print Loop
and JIT-compiling at every interaction. In practice, that works very
well (even when emitting C code instead of using libgccjit). I was able
to do that in my old GCC MELT project (which generated a C code,
compiled it into a plugin, at every REPL interaction).
Happy new year to everyone.
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
next prev parent reply other threads:[~2018-12-30 8:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-01 0:00 Marc Nieper-Wißkirchen
2018-01-01 0:00 ` Basile Starynkevitch [this message]
2018-01-01 0:00 ` Marc Nieper-Wißkirchen
2018-01-01 0:00 ` Basile Starynkevitch
2018-01-01 0:00 ` Basile Starynkevitch
2018-01-01 0:00 ` Marc Nieper-Wißkirchen
2018-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=1bc5aeb1-d251-0335-6103-eba3f6258456@starynkevitch.net \
--to=basile@starynkevitch.net \
--cc=jit@gcc.gnu.org \
--cc=marc@nieper-wisskirchen.de \
/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).