Re: AOT compiler (was: Running Compiled Guile Objects)

[Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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

> FWIW libgccjit builds position independent code, and can be used to
build dynamic libraries (which is what I believe gccemacs is doing).

To my limited experience, libgccjit can generate executable ELF and
relocatable .so, folks may pass gcc parameters for common considerations in
final codegen.

That's why I think libgccjit is good choice for Guile AOT. The whole
process and codegen can be consistent with common gcc cases and GNU
conventions.
Best regards.

On Sun, Dec 15, 2024, 10:59 Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Hi folks! Please reply AOT topic in this thread.
>
>
> > Indeed, it turns out that everyone using libgccjit is using it for
> ahead-of-time compilation, rather than jit-compilation.  Sorry about
> picking a bad name :)
>
> Thanks for the work!
>
> At least in Guile community, now that we already have JIT with GNU
> Lightening, we won't redundantly talk libgccjit for JIT. But I think it's
> still interesting to try libgccjit for JIT in my other project. :-p
>
> > Probably of most interest to guile developers might be the gccemacs
> project here:
>   https://akrl.sdf.org/gccemacs.html
>
>
> It looks super interesting!
>
> They created a high level IR just like GIMPLE, which named LIMPLE. It's
> the way I preferred in streaming-fist. The basic idea is to provide such an
> IR, then try to replace 'bytecode' in Guile compiler tower codegen. And
> they choose SBCL for it, I think it can inspire people who are interested
> in Guile AOT. Or maybe they could consider to change to Guile to save a lot
> of time for both Guile and Emacs.
>
> The compiler tower is so flexible that it's possible to try it as a
> plugin.
>
> I agreed with @mikael about losing weight of Guile. The AOT feature can be
> a plugin to install as guild tools. Of course, plugin unnecessarily mean it
> will be small......
>
>
> Best regards.
>
> On Sun, Dec 15, 2024, 02:45 Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> Thanks for the inspiring sharing! 👏
>>
>> On Sun, Dec 15, 2024, 02:39 Basile Starynkevitch <
>> basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org> wrote:
>>
>>> On Sun, 2024-12-15 at 02:21 +0900, Nala Ginrut wrote:
>>>
>>> @basile I'm glad you raise this topic, I've played lobgccjit with a toy
>>> project.
>>> https://gitlab.com/hardenedlinux/screaming-fist
>>>
>>> I would say libgccjit is a wrong name since it's more like a tool for
>>> AOT.
>>> Of course, one may still use it for JIT, however you have to do your own
>>> work for JIT and finally use libgccjit for codegen. 😁
>>>
>>> Best regards.
>>>
>>>
>>> You basically are right. If you want to use get a fast just-in-time
>>> compilation, libgccjit might not be the right tool.
>>>
>>> But in practice, current computers are so fast that I think that in
>>> practice libgccjit is quite usable, and it can be tuned to various GCC
>>> optimization strategy.
>>>
>>> A few years ago I did experiment (see https://arxiv.org/abs/1109.0779 ...)
>>> generation of C++ code which (on Linux desktop) was GCC compiled to a
>>> plugin and dlopen-ed. This works quite well with an elapsed time suitable
>>> for human users.
>>>
>>> A related experiment is my manydl.c thing on
>>> https://github.com/bstarynk/misc-basile - it is/was a toy program that
>>> I wrote which generates a lot of random C code (in many thousands of C
>>> files), compile it to a plugin, and use dlopen and dlsym. It shows that on
>>> Linux a process can successfully dlopen do many hundred thousands of
>>> plugins (and never bother dlclose-ing them)
>>>
>>> BTW in France the Lisp syntax and Scheme semantics of GNU guile is sadly
>>> becoming impopular. I know few persons using it.
>>>
>>> Just in case I am attaching a few PDF files on RefPerSys.
>>>
>>> Some ideas of RefPerSys originated from books and papers by by Jacques
>>> Pitrat
>>> https://en.wikipedia.org/wiki/Jacques_Pitrat
>>>
>>> Please mention RefPerSys to your colleagues and forward them this email.
>>>
>>> Thanks
>>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: Basile Starynkevitch <basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org>
>>> Date: Sun, Dec 15, 2024, 02:11
>>> Subject: Re: Running Compiled Guile Objects
>>> To: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Hakan Candar <
>>> hakancandar-g/b1ySJe57IN+BqQ9rBEUg@public.gmane.org>
>>> Cc: guile-user-mXXj517/zsQ@public.gmane.org <guile-user-mXXj517/zsQ@public.gmane.org>, <jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org>
>>>
>>>
>>> On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
>>> > Hi Hakan!
>>> > The current Guile is not AOT yet. Although the object file is ELF,
>>> > it's
>>> > just bytecode wrapped ELF header. So you can't run it as a regular
>>> > executable file.
>>> >
>>>
>>> Those willing to contribute a proper ahead-of-time compiler to GNU
>>> guile could use the GNU CC libgccjit library which is part of the GCC
>>> compiler.
>>> https://gcc.gnu.org/onlinedocs/jit/
>>>
>>> This libgccjit layer of the GCC compiler is stable and maintained C API
>>> and has some obsolete C++ API (which seems unmaintained in december
>>> 2024). Most of the libgccjit code is internally coded (under GPL
>>> license) in C++, but the stable API is for C.
>>>
>>> I am using the C API of libgccjit in the RefPerSys open source
>>> inference engine project (GPLv3+ licensed) on
>>> https://github.com/RefPerSys/RefPerSys/
>>>
>>> Both libgccjit and GNU lightning (see
>>> https://www.gnu.org/software/lightning/ ...) could be a basis for
>>> adding a genuine compilation layer to GNU guile. And RefPerSys uses
>>> both.
>>>
>>> I guess a significant issue would be to use libgccjit (or GNU
>>> lightning) with GUILE's garbage collector (which seems to be Boehm
>>> conservative GC).
>>>
>>> The RefPerSys project has a precise garbage collector and some
>>> persistence (to textual files). Since it is GPLv3+ licensed, its code
>>> could be reused in a future GUILE major version. RefPerSys is mostly
>>> coded in C++.
>>>
>>> I did contribute to GCC long time ago and hope that RefPerSys could
>>> become a GNU project (but don't know how to make that happen)
>>>
>>>
>>> --
>>>
>>> Basile STARYNKEVITCH           <basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org>8 rue de la Faïencerie
>>> 92340 Bourg-la-Reine,          France <https://www.google.com/maps/search/8+rue+de+la+Fa%C3%AFencerie%0D%0A92340+Bourg-la-Reine,++++++++++France?entry=gmail&source=g>http://starynkevitch.net/Basile & https://github.com/bstarynk
>>>
>>>

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