From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Thu, 02 Jan 2020 17:55:57 +0000 Message-ID: References: <83tv5mp48l.fsf@gnu.org> <83sgl0lchm.fsf@gnu.org> <83imlwl9vm.fsf@gnu.org> <20200102165229.u5y4tzkgfuypibcy@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="82679"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 02 18:56:16 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1in4hj-000LLE-P9 for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 18:56:15 +0100 Original-Received: from localhost ([::1]:43634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1in4hi-00082x-8D for ged-emacs-devel@m.gmane.org; Thu, 02 Jan 2020 12:56:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39113) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1in4hb-00082r-3H for emacs-devel@gnu.org; Thu, 02 Jan 2020 12:56:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1in4hZ-0001YU-P1 for emacs-devel@gnu.org; Thu, 02 Jan 2020 12:56:07 -0500 Original-Received: from mx.sdf.org ([205.166.94.20]:55842) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1in4hZ-0001WT-I0; Thu, 02 Jan 2020 12:56:05 -0500 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 002HtxcD023820 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Thu, 2 Jan 2020 17:55:59 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 002HtvJg029312; Thu, 2 Jan 2020 17:55:57 GMT In-Reply-To: <20200102165229.u5y4tzkgfuypibcy@Ergus> (Ergus's message of "Thu, 2 Jan 2020 17:52:29 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 205.166.94.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243873 Archived-At: Ergus writes: > Maybe a bit orthogonal to where the thread is going. But I have seen > that libgccjit is in alpha stage and has been like that for years > (according to the page). The source is included in gcc, but not compiled > by default in any distribution. I don't find distributions providing it > with the gcc bundle (I can ask for it's inclusion in arch, but I have no > idea about the others). AFAIK libgccjit is distributed by many (mosts?) distros including: debian, fedora, ubuntu. I guess this can easily improve further if Emacs choose to adopt it. > Andrea, are you aware about the progress of the development of libgccjit > and some estimation about when it is going to be stable? Because I can't > ask for the inclusion of alpha libraries in the distros. > > Very thanks for this, > Ergus > I don't know, in the last year I've up-streamed a bunch of patches to extend it and keep it functional for gcc 9 and the upcoming 10 but I'm not the maintainer. As a consequence regarding the alpha classification I have no precise info. I invite you to ask on jit@gcc.gnu.org, I'll be interested in reading the answer and I think is also important to manifest the interest we have on that. On the stability point: consider that libgccjit is a "relatively" thin layer in front of the gcc pipeline. In my experience I can tell you that the buggynes of this layer can typically impact the guy how is writing the code generator. It means that if you are generating invalid code and libgccjit does not catch it you'll get an ICE. It can be annoying (unless one likes to work into gcc) but is effectively more of a developer problem and if happen typically does not impact the final user and the stability of the shipped code. I think for Emacs adopting the use of libgccjit would help gcc giving momentum for keep on having a good jitter and Emacs for being able to use this direct interface into gcc. I see it as a win-win opportunity for both and for GNU as a consequence. That said if we decide to go for the other direction I've no problem in investing some time to rewrite the final pass to target C instead. Andrea -- akrl@sdf.org