* Re: existing C frontend for libgccjit?
[not found] <xUyN-um9ScbmLylXsJiiBi5lDN-EqVJrG7l2Twf_EURFKAXh5KnTSwEbYNjnZEtTaeET3RoMqTTeDsMkz3TnQJMSFJt93gcmVQolubmOUnM=@zhuyi.fan>
@ 2023-10-07 14:47 ` Basile Starynkevitch
2023-10-07 15:26 ` Basile Starynkevitch
0 siblings, 1 reply; 2+ messages in thread
From: Basile Starynkevitch @ 2023-10-07 14:47 UTC (permalink / raw)
To: jit
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
On 10/7/23 16:43, Schrodinger ZHU Yifan wrote:
> Hi,
>
> In my case, I wanted to include inline definitions in a header file
> into a context. Is there a way to this without writing all the functions?
I don't know about it.
An alternative (generating *less efficient* code) could be to consider
using GNU lightning. https://www.gnu.org/software/lightning/
GNU lightning generates "unoptimized" code, but it generates it faster
than libgccjit.
Another alternative could be to develop your GCC plugin generating
(using GIMPLE representation) some C code (which you could later pass to
GCC and compile, on Linux, as a shared object)
Regards.
--
Basile Starynkevitch -http://starynkevitch.net/Basile/
email:<basile@starynkevitch.net> (near Paris, France)
only mines opinions - les opinions sont seulement miennes
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: existing C frontend for libgccjit?
2023-10-07 14:47 ` existing C frontend for libgccjit? Basile Starynkevitch
@ 2023-10-07 15:26 ` Basile Starynkevitch
0 siblings, 0 replies; 2+ messages in thread
From: Basile Starynkevitch @ 2023-10-07 15:26 UTC (permalink / raw)
To: jit
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On 10/7/23 16:47, Basile Starynkevitch wrote:
>
>
> On 10/7/23 16:43, Schrodinger ZHU Yifan wrote:
>> Hi,
>>
>> In my case, I wanted to include inline definitions in a header file
>> into a context. Is there a way to this without writing all the functions?
>
>
> I don't know about it.
>
>
> An alternative (generating *less efficient* code) could be to consider
> using GNU lightning. https://www.gnu.org/software/lightning/
>
> GNU lightning generates "unoptimized" code, but it generates it faster
> than libgccjit.
>
> Another alternative could be to develop your GCC plugin generating
> (using GIMPLE representation) some C code (which you could later pass
> to GCC and compile, on Linux, as a shared object)
>
Of course, this won't easily work for C++ exceptions (so try or
|GIMPLE_TRY)|, GCC builtins, OpenMP, asm statements. I was thinking of
some kind of portable C code not using GCC features like OpenACC,
builtins, vector code, etc etc.
BTW, you could be interested by the LTO (link-time optimization)
framework of GCC (and GNU binutils). Basically, the GIMPLE code is then
written inside (augmented) *.o object files.
In the RefPerSys open source inference engine project (see some code on
https://github.com/RefPerSys/RefPerSys/ still buggy), we probably will
either generate C++ files at runtime or use GNU lightning.
Observe that generating C or GNU lightning code is usually easy. On
Linux an approach is to generate C code and compile it then dlopen it.
This can be done many thousands of times (see the useless
https://github.com/bstarynk/misc-basile/blob/master/manydl.c showing
that a Linux process can do many thousands of dlopen at once....)
||
--
Basile Starynkevitch -http://starynkevitch.net/Basile/
email:<basile@starynkevitch.net> (near Paris, France)
only mines opinions - les opinions sont seulement miennes
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-10-07 15:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <xUyN-um9ScbmLylXsJiiBi5lDN-EqVJrG7l2Twf_EURFKAXh5KnTSwEbYNjnZEtTaeET3RoMqTTeDsMkz3TnQJMSFJt93gcmVQolubmOUnM=@zhuyi.fan>
2023-10-07 14:47 ` existing C frontend for libgccjit? Basile Starynkevitch
2023-10-07 15:26 ` Basile Starynkevitch
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).