From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: native compilation units Date: Sat, 11 Jun 2022 12:13:44 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000075af6505e12e5707" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32670"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 11 18:21:39 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 1o03rn-0008I9-4d for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Jun 2022 18:21:39 +0200 Original-Received: from localhost ([::1]:55440 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o03rl-0003NH-W5 for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Jun 2022 12:21:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38496) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o03kM-0007Ea-T5 for emacs-devel@gnu.org; Sat, 11 Jun 2022 12:13:58 -0400 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:40755) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o03kL-0000PV-Ba for emacs-devel@gnu.org; Sat, 11 Jun 2022 12:13:58 -0400 Original-Received: by mail-lf1-x131.google.com with SMTP id t25so2798062lfg.7 for ; Sat, 11 Jun 2022 09:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+48IcI4oA+faRwnwdmIHIT2xegViKgLXH74pxmH1oik=; b=gS1JFwPZcY7u9qsSH0Yrvtdz3QFIxbuYjdDzGN+vt+RzQtBT0Ux5aWnNOOxfWPb6x5 wa7irFADep4aY84QWJa8N4fA18uuegqr9TfEndYvHQOgxdQKVUFxSBJKJYOqfPHARS3a IpxxNCyvwSyxMj+8hUFY/Kgg3Brk5RJqeNOeFNnA4mueaJ8/BwB+9PHdjljoCArmC/tX c7R7t0ynVGwxPzjrOP3X4JVtCIXV33krNLSpCeqhfonuI5bVgZ7GgsjRFXviwqv6D2n0 /dIuNDhlggmJ9nBRyXDSxwe/mV6Vhasj5P3hkZanPctftVHeBZEPtIw2E56mKJY5q5/d YjGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+48IcI4oA+faRwnwdmIHIT2xegViKgLXH74pxmH1oik=; b=eBFDp6DtThb0qfo1TAdkGCVoSJR+gd4PPwc1XTYLUemrqVgsa6O4xcqlE9lD8pOvNy 7q5t5GCoe37AdfcVqPG/OlYQG3hAkkLnZEl+vXpPewW0qFwJi+aSiD7TZkOAtzMoMMXf O2YSvBWMm7LTF1k169pf4qCSTrByR2WFwGY+MpTiGblOSFwCJYetNZlwn4steqLa7Rfq 8o3XrBWUchF/XBWpn6jhWq5sLWKb1437i8UZccx4MamWd1Ve0n7Ax3NHJ88Vx2q/eEUO t4gbpjr7uhSIBy74HMEtRHO/wTtrPiGbuPSGu87AbbiNzJLcYk1MCT0g+qAsYiteHxDl LuHQ== X-Gm-Message-State: AOAM533m6ABhveVdZpHFg4sckYRVm6mebaXQ6Fbhb7saH68S6CFR2/sT 5p9mVoNNJdJCcDjNHB+sKiTlnlMn9V70LVjD6pgOP8in X-Google-Smtp-Source: ABdhPJzauGlJetpviLHZ5nJDlzZrP0PGdJWjeCXETTUNg29clDztBd9DwAjaZmCHTALtrmbasTUKKrUAr4WiN4WG0og= X-Received: by 2002:a05:6512:228c:b0:479:7a60:5e0c with SMTP id f12-20020a056512228c00b004797a605e0cmr10931609lfu.323.1654964035627; Sat, 11 Jun 2022 09:13:55 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=owinebar@gmail.com; helo=mail-lf1-x131.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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-Mailman-Approved-At: Sat, 11 Jun 2022 12:20:11 -0400 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:291041 Archived-At: --00000000000075af6505e12e5707 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 8, 2022, 2:56 AM Andrea Corallo wrote: > Stefan Monnier writes: > > > >> It's not clear to me whether those points are limited to call > >> sites or not. > > > > I believe it is: the optimization is to replace a call via `Ffuncall` to > > a "symbol" (which looks up the value stored in the `symbol-function` > > cell), with a direct call to the actual C function contained in the > > "subr" object itself (expected to be) contained in the > > `symbol-function` cell. > > > > Andrea would know if there are other semantic-non-preserving > > optimizations in the level 3 of the optimizations, but IIUC this is very > > much the main one. > > Correct that's the main one: it does that for all calls to C primitives > and for all calls to lisp function defined in the same compilation unit. > > Other than that speed 3 enables pure function optimization and self tail > recursion optimization. > Would it make sense to add a feature for declaring a function symbol value is constant and non-advisable, at least within some notion of explicitly named scope(s)? That would allow developers to be more selective about which functions are "exported" to library users, and which are defined as global function symbols because it's more convenient than wrapping everything in a package/module/namespace in a giant cl-flet and then explicitly "exporting" functions and macros via fset. Then intraprocedural optimization within the named scopes would be consistent with the language. I'm thinking of using semantic/wisent for a modern for a proprietary language. I am curious whether these optimizations are used or usable in that context. Lynn --00000000000075af6505e12e5707 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 8, 2022, 2:56 AM Andrea Corallo <akrl@sdf.org> wrote:
Stefan Monnier <monnier@iro.umontreal.ca> writes= :


>> It's not clear to me whether those points are limited to call<= br> >> sites or not.
>
> I believe it is: the optimization is to replace a call via `Ffuncall` = to
> a "symbol" (which looks up the value stored in the `symbol-f= unction`
> cell), with a direct call to the actual C function contained in the > "subr" object itself (expected to be) contained in the
> `symbol-function` cell.
>
> Andrea would know if there are other semantic-non-preserving
> optimizations in the level 3 of the optimizations, but IIUC this is ve= ry
> much the main one.

Correct that's the main one: it does that for all calls to C primitives=
and for all calls to lisp function defined in the same compilation unit.
Other than that speed 3 enables pure function optimization and self tail recursion optimization.

<= /div>
=C2=A0Would it make sense to add a feature for decla= ring a function symbol value is constant and non-advisable, at least within= some notion of explicitly named scope(s)?=C2=A0 That would allow developer= s to be more selective about which functions are "exported" to li= brary users, and which are defined as global function symbols because it= 9;s more convenient than wrapping everything in a package/module/namespace = in a giant cl-flet and then explicitly "exporting" functions and = macros via fset.
Then intraprocedural optimization w= ithin the named scopes would be consistent with the language.
I'm thinking of using semantic/wisent for a modern for a prop= rietary language.=C2=A0 I am curious whether these optimizations are used o= r usable in that context.=C2=A0=C2=A0

Lynn


<= /div>
--00000000000075af6505e12e5707--