From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26083 invoked by alias); 30 Dec 2018 15:53:12 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 26071 invoked by uid 89); 30 Dec 2018 15:53:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=pico, visited, HContent-Transfer-Encoding:8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: relay5-d.mail.gandi.net Received: from relay5-d.mail.gandi.net (HELO relay5-d.mail.gandi.net) (217.70.183.197) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 30 Dec 2018 15:53:10 +0000 X-Originating-IP: 193.248.54.187 Received: from [192.168.1.2] (lstlambert-656-1-266-187.w193-248.abo.wanadoo.fr [193.248.54.187]) (Authenticated sender: basile@starynkevitch.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 7A4FC1C0003; Sun, 30 Dec 2018 15:53:07 +0000 (UTC) Subject: Re: Incremental compilation To: =?UTF-8?Q?Marc_Nieper-Wi=c3=9fkirchen?= Cc: jit@gcc.gnu.org References: <1bc5aeb1-d251-0335-6103-eba3f6258456@starynkevitch.net> From: Basile Starynkevitch Message-ID: Date: Mon, 01 Jan 2018 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00012.txt.bz2 On 12/30/18 4:04 PM, Marc Nieper-Wißkirchen wrote: > Am So., 30. Dez. 2018 um 13:28 Uhr schrieb Basile Starynkevitch > : > > > You could, once all macros have been compiled, regenerate a single > "shared object" for all your library, but that is an optimization. The > main reason to do so would be to avoid wasting virtual address space by > having many thousands of shared objects. I am not sure it is worthwhile. > The reason why I would like to have a single shared object is for the > convenience of the user. The compiler should produce a single shared > object from a Scheme library definition which can then later be > visited/invoked in lieu of loading the Scheme source code of the > library. Then you could compile twice the code. Alternatively, you could compile each function once into a .pic.o position-independent code object file. When doing the incremental compilation, you also need to convert each of these into its own .so file (and you would fork a ld or gcc process for that; it should run quickly). BTW, since libgccjit is really a wrapper above GCC, you could generate once the position-indenpendent code object files (so usinggcc_jit_context_add_command_line_option to ask for -fPIC then using gcc_jit_context_compile_to_file) of each function. Then you would fork a gcc or ld process to link all these *.pic.o into a single .so; this would be reasonably quick. Take advantage that libgccjit is just a front-end to GCC. It fakes to be a JIT compiler, but it is not really one. Its main advantage is to avoid requiring you to emit C code in files. Cheers. -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France