From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by sourceware.org (Postfix) with ESMTPS id 10AE93858C53 for ; Sat, 7 Oct 2023 15:26:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 10AE93858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=starynkevitch.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=starynkevitch.net Received: by mail.gandi.net (Postfix) with ESMTPSA id B9A6D1C0004 for ; Sat, 7 Oct 2023 15:26:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------jMQ9jRflGxWe0xP6StjK01ZE" Message-ID: <238f808a-664f-4ad5-b310-72bc4b972e5b@starynkevitch.net> Date: Sat, 7 Oct 2023 17:26:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: existing C frontend for libgccjit? Content-Language: en-US To: jit@gcc.gnu.org References: From: Basile Starynkevitch In-Reply-To: X-GND-Sasl: basile@starynkevitch.net X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,HTML_MESSAGE,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------jMQ9jRflGxWe0xP6StjK01ZE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: (near Paris, France) only mines opinions - les opinions sont seulement miennes --------------jMQ9jRflGxWe0xP6StjK01ZE--