public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
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

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