Re: existing C frontend for libgccjit?

[Basile Starynkevitch <basile@starynkevitch.net>]

[-- 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