public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Marc Nieper-Wißkirchen" <marc@nieper-wisskirchen.de>
To: Basile Starynkevitch <basile@starynkevitch.net>
Cc: jit@gcc.gnu.org
Subject: Re: Incremental compilation
Date: Tue, 01 Jan 2019 00:00:00 -0000	[thread overview]
Message-ID: <CAEYrNrQXyGAxhvHwQ1bv-Y2vzFcuhUm+saZYKHKR23pnBh+G_w@mail.gmail.com> (raw)
In-Reply-To: <fb2c33a4-1505-6930-ccdd-ff4f35a17a73@starynkevitch.net>

Am So., 30. Dez. 2018 um 16:53 Uhr schrieb Basile Starynkevitch
<basile@starynkevitch.net>:
>
>
> On 12/30/18 4:04 PM, Marc Nieper-Wißkirchen wrote:
> > Am So., 30. Dez. 2018 um 13:28 Uhr schrieb Basile Starynkevitch
> > <basile@starynkevitch.net>:
> >
> >
> > You could, once all macros have been compiled, regenerate a single
> > "shared object" for all your library, but that is an optimization. The
> > main reason to do so would be to avoid wasting virtual address space by
> > having many thousands of shared objects. I am not sure it is worthwhile.
> > The reason why I would like to have a single shared object is for the
> > convenience of the user. The compiler should produce a single shared
> > object from a Scheme library definition which can then later be
> > visited/invoked in lieu of loading the Scheme source code of the
> > library.
>
> Then you could compile twice the code.
>
> Alternatively, you could compile each function once into a .pic.o
> position-independent code object file. When doing the incremental compilation, you also need to convert each of these into its own .so file
> (and you would fork a ld or gcc process for that; it should run quickly).
>
> BTW, since libgccjit is really a wrapper above GCC, you could generate once the position-indenpendent code object files
> (so usinggcc_jit_context_add_command_line_option to ask for -fPIC then using
> gcc_jit_context_compile_to_file) of each function. Then you would fork a
> gcc or ld process to link all these *.pic.o into a single .so; this
> would be reasonably quick. Take advantage that libgccjit is just a
> front-end to GCC. It fakes to be a JIT compiler, but it is not really
> one. Its main advantage is to avoid requiring you to emit C code in
> files. Cheers.

Another advantage of libgccjit (vs invoking GCC directly) is that it
abstracts away issues like locating the GCC binary on the target
system, handling of temporary files, etc.

Maybe it makes sense if libgccjit exposes that part as an API to the
user as well.

-- Marc

  reply	other threads:[~2019-01-01 12:08 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
2018-01-01  0:00   ` Marc Nieper-Wißkirchen
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 [this message]
2018-01-01  0:00     ` Basile Starynkevitch

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=CAEYrNrQXyGAxhvHwQ1bv-Y2vzFcuhUm+saZYKHKR23pnBh+G_w@mail.gmail.com \
    --to=marc@nieper-wisskirchen.de \
    --cc=basile@starynkevitch.net \
    --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).