unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: "Lluís Vilanova" <vilanova@ac.upc.edu>
To: Mikael Djurfeldt <mikael@djurfeldt.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: Native code generation and gcc
Date: Mon, 05 Dec 2016 17:18:43 +0100	[thread overview]
Message-ID: <878truxsbg.fsf@fimbulvetr.bsc.es> (raw)
In-Reply-To: <CAA2Xvw+80=6n=CK46xTjCbwQvfu3LqqT_FsU96VoMMPWhu5JJw@mail.gmail.com> (Mikael Djurfeldt's message of "Sat, 3 Dec 2016 15:52:12 +0100")

Mikael Djurfeldt writes:

> [I apologize beforehand for being completely out of context.]
> Are there fundamental reasons for not re-using the gcc backends for native code generation? I'm thinking of the (im?)possibility to convert the cps to some of the intermediate languages of gcc.

> If it wouldn't cause bad constraints the obvious gain is the many targets (for free), the gcc optimizations, not having to maintain backends and free future development.

> Of course, there's the practical problem that gcc needs to be adapted for this kind of use---but shouldn't it be adapted that way anyway? :)

> Just an (old) idea...

> Mikael

Guile 2.1 has a register-base bytecode VM that makes using a code generation
library like GNU lightning [1] a convenient alternative. In fact, that's the
library used by nash [2] (an experimental Guile VM that generates native code
for hot routines). You also have the experimental GCC JIT interface [3] to
achieve similar goals (available upstream since GCC 5, I think).

IMO, if guile wants to go the tracing JIT way (like nash), it should store the
CPS representation of routines to be able to iteratively apply more heavy-weight
optimizations as the routine becomes hotter (called more frequently).

For example, you could start with the current state. If the routine is called
many times with the same argument types, you can create a version specialized
for these types, opening more unboxing possibilities (the routine entry point
would then have to be a version dispatcher). If a routine version later becomes
hotter, re-compile that version into native code.

One open question is whether the VM needs to be changed to count routine
"hotness" efficiently (as in nash), or if a simple routine prelude inserted by
guile's compiler tower could do that almost as efficiently (the bytecode ISA
might need new atomic integer operations to cope with routine tracing in a
multi-threaded app).

Also, these all are no small tasks.

[1] https://www.gnu.org/software/lightning/
[2] https://github.com/8c6794b6/guile-tjit
[3] https://gcc.gnu.org/wiki/JIT

Cheers,
  Lluis



  parent reply	other threads:[~2016-12-05 16:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAA2XvwKQubnmb4cQXGyP80GjT7_001-xxhFrdP3SKL3+6HkuVw@mail.gmail.com>
     [not found] ` <CAA2XvwJjWigCcRBmk3dNJH4+0bEDTOoyL1=o5qj8JpbhuLm-xw@mail.gmail.com>
     [not found]   ` <CAA2XvwKb9hPUyeOvSZo0fWpDDEzSgjaw_Xehz4rMob1TyNucEA@mail.gmail.com>
     [not found]     ` <CAA2XvwLwPP728sAeV1mNmDVmGe_V0buiT_xgMDMihBqNXX_RgA@mail.gmail.com>
     [not found]       ` <CAA2Xvw+RCs4fMU5Pw6QP8ofWtX0k8EbnpLR5KkYUMvLbgopGZw@mail.gmail.com>
     [not found]         ` <CAA2XvwKRp1KDk285zTH3xLkEhHFcN=_owDf2RFPzt-JnXhxLAg@mail.gmail.com>
     [not found]           ` <CAA2XvwJUFZ-A+9sbNtomOCiCe=CR+WMAuuTdybUjocVgHmMZ-g@mail.gmail.com>
     [not found]             ` <CAA2Xvw+mzfKyfiC44VWrZcHRtwgYRDqci9ZbUgUndNq2HEL6tg@mail.gmail.com>
     [not found]               ` <CAA2XvwJmfmykKXrb+zgoEWs7LrBfWBgjP+jOYvdjT06=WAFfFw@mail.gmail.com>
2016-12-03 14:52                 ` Native code generation and gcc Mikael Djurfeldt
2016-12-04 10:09                   ` Helmut Eller
2016-12-04 15:17                   ` Greg Troxel
2016-12-05 16:18                   ` Lluís Vilanova [this message]
2016-12-11 18:09                     ` Mikael Djurfeldt
2016-12-11 18:31                       ` Stefan Monnier

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

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878truxsbg.fsf@fimbulvetr.bsc.es \
    --to=vilanova@ac.upc.edu \
    --cc=guile-devel@gnu.org \
    --cc=mikael@djurfeldt.com \
    /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).