From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128146 invoked by alias); 1 Jan 2019 12:08:11 -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 128135 invoked by uid 89); 1 Jan 2019 12:08:11 -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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=reasonably, locating, wasting, visited X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: mail-pf1-f175.google.com Received: from mail-pf1-f175.google.com (HELO mail-pf1-f175.google.com) (209.85.210.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 01 Jan 2019 12:08:09 +0000 Received: by mail-pf1-f175.google.com with SMTP id b7so14061055pfi.8 for ; Tue, 01 Jan 2019 04:08:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T121ON48fFeGvmwaoegWoZ1CUQ9HyS0atbBLi1LVtX4=; b=sMKv9wTb7S6B1MYJ8jPXpBWnVCF8Marb9IpfmmyKAvTmHr6h6BTHFk7EGlFtxmLhAr dlz+Bg4JMsfPrV3DBfH/qYjn6aYNDifnZZJodsjWogUu0f96oTdHvdfe75JG/N5Ag2Ui oqWblr0NUPcTTdKlQ4wTfACc+Z1Q78Uqnpe4T5X+ZeRGrWR7Ubeh41snF7rwrnFXRXjZ hWdl35+r5r2fH/hSOHV6hgpqK/Jm9jO7vEYWCpDAlhzkyoOlLA4RKsrBP0O4cgxKOOsk WDE9VU86gJEkd8MlY9Pb86ulECm1b5zmNxcTxDqWVncbbxQEp/1k7tieyO4bil+m2tFR Yk/Q== X-Gm-Message-State: AJcUukfPMAYQnkDYUGvF/ePpZFvDq/NGrwPOOJ4XuDEesIDVDRqXYhL4 PXH3yFT3KvkWl126KZgdwz0KBheZlcazIVhS4GEx+7Sd X-Google-Smtp-Source: ALg8bN4hfFb+xhOFPeON55ZCCDyD1U+DLjpDz2gGH3hqjbG76qq9aQw73r8pn37YWe+cbLj6EX4pvtciZsIx26gTGMk= X-Received: by 2002:a62:4d81:: with SMTP id a123mr42300724pfb.122.1546344487071; Tue, 01 Jan 2019 04:08:07 -0800 (PST) MIME-Version: 1.0 References: <1bc5aeb1-d251-0335-6103-eba3f6258456@starynkevitch.net> In-Reply-To: From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: Subject: Re: Incremental compilation To: Basile Starynkevitch Cc: jit@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00001.txt.bz2 Am So., 30. Dez. 2018 um 16:53 Uhr schrieb Basile Starynkevitch : > > > On 12/30/18 4:04 PM, Marc Nieper-Wi=C3=9Fkirchen 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 compila= tion, 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 on= ce the position-indenpendent code object files > (so usinggcc_jit_context_add_command_line_option to ask for -fPIC then us= ing > 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. Another advantage of libgccjit (vs invoking GCC directly) is that it abstracts away issues like locating the GCC binary on the target system, handling of temporary files, etc. Maybe it makes sense if libgccjit exposes that part as an API to the user as well. -- Marc