unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* guile and libgccjit
@ 2021-10-09 23:06 Andy Tai
  2021-10-10  7:57 ` Linus Björnstam
  0 siblings, 1 reply; 3+ messages in thread
From: Andy Tai @ 2021-10-09 23:06 UTC (permalink / raw)
  To: guile-devel

[-- Attachment #1: Type: text/plain, Size: 85 bytes --]

can guile make use of libgccjit?

would be an interesting optional addition to guile

[-- Attachment #2: Type: text/html, Size: 326 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: guile and libgccjit
  2021-10-09 23:06 guile and libgccjit Andy Tai
@ 2021-10-10  7:57 ` Linus Björnstam
  2021-10-10  8:49   ` tomas
  0 siblings, 1 reply; 3+ messages in thread
From: Linus Björnstam @ 2021-10-10  7:57 UTC (permalink / raw)
  To: Andy Tai, guile-devel

The the current JIT is, in my understanding, more or less a stepping stone towards native compilation. The current JIT is very small and lightweight, without any tracing, meaning things like register allocation is flexible going forward.

I am not a maintainer, nor heavily involved, but I believe libgccjit would be a step sideways considering the above. 

Best regards
  Linus Björnstam

On Sun, 10 Oct 2021, at 01:06, Andy Tai wrote:
> can guile make use of libgccjit?
>
> would be an interesting optional addition to guile



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: guile and libgccjit
  2021-10-10  7:57 ` Linus Björnstam
@ 2021-10-10  8:49   ` tomas
  0 siblings, 0 replies; 3+ messages in thread
From: tomas @ 2021-10-10  8:49 UTC (permalink / raw)
  To: guile-devel

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On Sun, Oct 10, 2021 at 09:57:13AM +0200, Linus Björnstam wrote:
> The the current JIT is, in my understanding, more or less a stepping stone towards native compilation. The current JIT is very small and lightweight, without any tracing, meaning things like register allocation is flexible going forward.
> 
> I am not a maintainer, nor heavily involved, but I believe libgccjit would be a step sideways considering the above. 

I think there's some (very readable!) rationale on why Andy chose a
relatively "simple" JIT in his blog [1]. It's a fork of GNU lightning.
The post explains why the powerful optimisations built into new
versions of Lightning seem contraproductive for Guile. Since libgccjit
will have even more powerful optimisations (it's gcc, after all!), I
guess the same arguments hold.

Note that Emacs is currently integrating an Elisp compiler based on
libgccjit. But as far as I can see, it's more an AOT compiler than a
JIT.

Cheers
[1] https://wingolog.org/archives/2019/05/24/lightening-run-time-code-generation
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-10-10  8:49 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-09 23:06 guile and libgccjit Andy Tai
2021-10-10  7:57 ` Linus Björnstam
2021-10-10  8:49   ` tomas

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