From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: native compilation units Date: Sun, 19 Jun 2022 19:02:50 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29527"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Andrea Corallo , emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 20 01:04:22 2022 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 1o33xt-0007U2-N9 for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Jun 2022 01:04:21 +0200 Original-Received: from localhost ([::1]:57688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o33xs-00066y-92 for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Jun 2022 19:04:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44814) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o33wb-0005PX-9g for emacs-devel@gnu.org; Sun, 19 Jun 2022 19:03:05 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3829) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o33wW-000783-4t for emacs-devel@gnu.org; Sun, 19 Jun 2022 19:03:00 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 70B9080931; Sun, 19 Jun 2022 19:02:54 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DCBCA802A5; Sun, 19 Jun 2022 19:02:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1655679772; bh=R1l5sM5Z63B2DStlQepky5CE9eiWQJXUvDGs4Q+CpWQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=i6XxfQYrxoKO5KvP3Sst8K0MQB8PDw/W/ieMT322ijbTmdnVjOakCrxEw5+eb0Ei8 wXNYIQn4rauuIG89Uv+rcXMBCKqCeY180A0bCak7LPXjziRb7ACrnrHyDr8on56OUt RKNLMNZzznKv52jMbNHUM6Fp0F3+wlZoNTabfd/8zaDqV8vSx/Zt3YFzBT0e4WLhpn kkMEPA1jIigWKXTpzsTzixSa/6lIZBw0LI32VgfF2pk4UyhPLQh/mdS5FOmTa3XoOc I1C/cvRgmgZtXPQA8LETD0ArF/rIZBXJCG5JXsxjFDin0JWdcXAe2QO0nxJU9A3UIl S9kxetm0cY+ZA== Original-Received: from alfajor (196.214.25.93.rev.sfr.net [93.25.214.196]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 00ADA120161; Sun, 19 Jun 2022 19:02:51 -0400 (EDT) In-Reply-To: (Lynn Winebarger's message of "Sun, 19 Jun 2022 13:52:35 -0400") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:291443 Archived-At: > Currently compiling a top-level expression wrapped in > eval-when-compile by itself leaves no residue in the compiled output, `eval-when-compile` has 2 effects: 1- Run the code within the compiler's process. E.g. (eval-when-compile (require 'cl-lib)). This is somewhat comparable to loading a gcc plugin during a compilation: it affects the GCC process itself, rather than the code it emits. 2- It replaces the (eval-when-compile ...) thingy with the value returned by the evaluation of this code. So you can do (defvar my-str (eval-when-compile (concat "foo" "bar"))) and you know that the concatenation will be done during compilation. > but I would want to make the above evaluate to an object at run-time > where the exported symbols in the obstack are immutable. Then it wouldn't be called `eval-when-compile` because it would do something quite different from what `eval-when-compile` does :-) > byte-code (or native-code) instruction arrays. This would in turn enable > implementing proper tail recursion as "goto with arguments". Proper tail recursion elimination would require changing the *normal* function call protocol. I suspect you're thinking of a smaller-scale version of it specifically tailored to self-recursion, kind of like what `named-let` provides. Note that such ad-hoc TCO tends to hit the same semantic issues as the -O3 optimization of the native compiler. E.g. in code like the following: (defun vc-foo-register (file) (when (some-hint-is-true) (load "vc-foo") (vc-foo-register file))) the final call to `vc-foo-register` is in tail position but is not a self call because loading `vc-foo` is expected to redefine `vc-foo-register` with the real implementation. > I'm not familiar with emacs's profiling facilities. Is it possible to > tell how much of the allocated space/time spent in gc is due to the > constant vectors of lexical closures? In particular, how much of the > constant vectors are copied elements independent of the lexical > environment? That would provide some measure of any gc-related > benefit that *might* be gained from using an explicit environment > register for closures, instead of embedding it in the > byte-code vector. No, I can't think of any profiling tool we currently have that can help with that, sorry :-( Note that when support for native closures is added to the native compiler, it will hopefully not be using this clunky representation where capture vars are mixed in with the vector of constants, so that might be a more promising direction (may be able to skip the step where we need to change the bytecode). Stefan