From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Wed, 04 Mar 2020 19:34:02 +0000 Message-ID: References: <83tv5mp48l.fsf@gnu.org> <83sgl0lchm.fsf@gnu.org> <83imlwl9vm.fsf@gnu.org> <83o8uegykm.fsf@gnu.org> <74dd94a9-28cb-a5fd-dbc7-ab21009834ad@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="129838"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Eli Zaretskii , Paul Eggert , Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 04 20:40:54 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j9Zsw-000Xe2-DY for ged-emacs-devel@m.gmane-mx.org; Wed, 04 Mar 2020 20:40:50 +0100 Original-Received: from localhost ([::1]:38914 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9Zsv-0006t7-G9 for ged-emacs-devel@m.gmane-mx.org; Wed, 04 Mar 2020 14:40:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46594) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9ZsM-00065f-Dn for emacs-devel@gnu.org; Wed, 04 Mar 2020 14:40:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9ZsL-0005RG-13 for emacs-devel@gnu.org; Wed, 04 Mar 2020 14:40:14 -0500 Original-Received: from mx.sdf.org ([205.166.94.20]:50870) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j9ZsJ-0005G4-7V; Wed, 04 Mar 2020 14:40:11 -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 024JY2t8020280 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 4 Mar 2020 19:34:03 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 024JY2wE010752; Wed, 4 Mar 2020 19:34:02 GMT In-Reply-To: (Andrea Corallo's message of "Sun, 16 Feb 2020 18:18:01 +0000") 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245237 Archived-At: Hi all, this is the usual update for the activity of the last 2/3 weeks on the native-comp branch. - I did some reorganization of the passes and reworked the allocation strategy for the relocable objects to avoid duplication and save heap space. - We now (finally) support multiple different builds on the same lisp code base. ~eln~ files are compiled in specific sub-folders taking in account host architecture and current Emacs configuration to disambiguate possible incompatibilities. As example a file ~.../foo.el~ will compile into something like ~.../x86_64-pc-linux-gnu-12383a81d4f33a87/foo.eln~. I've updated the load and 'go to definition' mechanisms to support this, so should be totally transparent to the user (if it's not is a bug). The same idea applies to all compilations, meaning main build as compiled packages. - Optimize qualities (read compilation flags) are now stored in every ~eln~ file. It's possible to inspect them for example as: #+BEGIN_SRC lisp (subr-native-comp-unit (symbol-function 'org-mode)) => # #+END_SRC We could store there other information we are interest in related to the compilation unit if we need. - Finally I've set up a docker image for people willing to test it without having to configure and compile Emacs and libgccjit. Now that I've learned how it works I plan to use it to setup a small CI to keep an eye that the latest GCC does not break with our build. I've took note of all of this as Update6 in the usual page. I'm generally very satisfied (surprised) about the stability of the toy. I'm looking forward going into compile time mitigation. I guess I'll start this weekend with deferred compilation and GCC profiling. Please let me know if there's some point I should address. Andrea -- akrl@sdf.org