From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97993 invoked by alias); 30 Dec 2018 15:04:27 -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 97981 invoked by uid 89); 30 Dec 2018 15:04:26 -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=visited, lieu, 8:er, hundred 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-pg1-f170.google.com Received: from mail-pg1-f170.google.com (HELO mail-pg1-f170.google.com) (209.85.215.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 30 Dec 2018 15:04:24 +0000 Received: by mail-pg1-f170.google.com with SMTP id s198so11893761pgs.2 for ; Sun, 30 Dec 2018 07:04:24 -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=rI+2JHRW0mv+44dSGiA7+cJl1GnhOa66FkowiWRTX6Q=; b=WKNSnfDYV7VDm0pOc5nxeN6X21DW4hgTK5/eluC9/pmEs6+hoSEzasXokh++dcN/Nq GOnq238jd/hgWJA7+97xq93fEK661/dMbpnI+azacDxS5E45WMfhGbB9NFkQ4wcIRvas C1FOqaGBxRd5Xn8Qh5LykGDZUeNFNFVjEDqdjtlBmX4o9DoUXts6N7f7zSm4HdMShZ4y ZqEoFtuudqyOsxhF8aLC9KrIrHiV0GMhwgq6vpJXgIdWzN0JPP8WuUNwgXtOKTXrVTsb IB4nE4uObq8jP63PCA4vHaB7cUh21esSssQr+LMOHE0vrcK1UCmXhQM7QKvWrdL5or46 MKEQ== X-Gm-Message-State: AJcUukfzAKgiQkSDFpb1nOAL+9+x2I7rwxN747MEgfKZ1IXcIW+T6t6y d73PKUgvLs8oXYBCrya/hX7U1THIN1iR/fhCI4xv1XmGJfw= X-Google-Smtp-Source: ALg8bN5km+kgkiyYUiqnxzoPXoLLOJwi4uftWNYG7A+O/jyw5LN5qsZNXG1bshyTW8KyY+m4dAVN31xLoCn8b91ENes= X-Received: by 2002:a63:6f0d:: with SMTP id k13mr4690944pgc.42.1546182262282; Sun, 30 Dec 2018 07:04:22 -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: Mon, 01 Jan 2018 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: 2018-q4/txt/msg00011.txt.bz2 Am So., 30. Dez. 2018 um 13:28 Uhr schrieb Basile Starynkevitch : > > > On 12/30/18 12:54 PM, Marc Nieper-Wi=C3=9Fkirchen wrote: > > > My use case is compiling a Scheme library. It contains macro > > definitions whose transformation procedures have to be compiled at > > first to expand subsequent parts of the library body. Furthermore, the > > compiled transformation procedures of global macro defintions have to > > appear in the final dynamic library as well. > > I am quite interested in your work, since I did (in the past) GCC MELT > http://starynkevitch.net/Basile/gcc-melt/ (which now is a dead project; > it was a Lisp dialect compiled to C or C++ for GCC extensions); I am > working on http://github.com/bstarynk/bismon right now, and you might be > interested in reading > http://starynkevitch.net/Basile/bismon-chariot-doc.pdf > > Is your project some open-source stuff? Could you give us the URL of its > source code? At the moment, most parts of the project is just in my head. I have written some code to be able to do some experiments but nothing is finished yet. As soon as I have something presentable, I'd love to share it with you. It will be GPL'd code. The goal of the project is to have a reasonably fast Scheme implementation that I can use for experiments with language extension. > In MELT, I also had macros similar to yours. So I believe I understand > your work quite well (since it is similar to what I did in GCC MELT, > which was a Lisp -but not Scheme- dialect with macros). In practice, you > still can compile every function in a separate *.so plugin. > > You could group several (unrelated) functions together by JIT compiling > them at once, but that is an optimization. > > 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. > Since you are implementing a Scheme, all your functions are in fact used > in closures (which contains a function pointer). So updating all the > required closures (to put there a function pointer to a newer code) > might be quite easy in practice. > > The potential issue is to "garbage collect" useless code. In your case, > that would mean doing dlclose in your GC. Do you want to do that? There will be two sources of (longer lived) compiled code: Libraries that have been loaded and functions generated by `eval'. The former will never be garbage collected. The latter will. `Eval' would (internally) return closures created that should be disposable by calling 'gcc_jit_result_release`. > Since you can in practice have many hundred thousands of useless > generated plugins, you might decide to never call dlclose (and accept > the "code segment leak" that follows). > > Again, I really am interested by your work. If you have any additional > references (draft reports, source code, etc...) please share them with > us if possible. I really should write up my concept. It isn't going to be finished this year, however. Best, Marc > > > Cheers > > -- > Basile STARYNKEVITCH =3D=3D http://starynkevitch.net/Basile > opinions are mine only - les opinions sont seulement miennes > Bourg La Reine, France > --=20 Prof. Dr. Marc Nieper-Wi=C3=9Fkirchen Universit=C3=A4t Augsburg Institut f=C3=BCr Mathematik Universit=C3=A4tsstra=C3=9Fe 14 86159 Augsburg Tel: 0821/598-2146 Fax: 0821/598-2090 E-Mail: marc.nieper-wisskirchen@math.uni-augsburg.de Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/