From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Towards a cleaner build: calc.el Date: Sun, 16 Jun 2019 17:51:53 -0400 Message-ID: References: <831rzvvsgp.fsf@gnu.org> <83y322vqvg.fsf@gnu.org> <83v9x6vpap.fsf@gnu.org> <52332265-2d02-a01c-e221-20b00b1edf86@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="260615"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 16 23:52:16 2019 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 1hcd4R-0015fp-KR for ged-emacs-devel@m.gmane.org; Sun, 16 Jun 2019 23:52:15 +0200 Original-Received: from localhost ([::1]:43120 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcd4Q-0002jL-M7 for ged-emacs-devel@m.gmane.org; Sun, 16 Jun 2019 17:52:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44763) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hcd4I-0002j3-TS for emacs-devel@gnu.org; Sun, 16 Jun 2019 17:52:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hcd4H-00014G-06 for emacs-devel@gnu.org; Sun, 16 Jun 2019 17:52:06 -0400 Original-Received: from [195.159.176.226] (port=44064 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hcd4F-00012g-E3 for emacs-devel@gnu.org; Sun, 16 Jun 2019 17:52:04 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hcd4C-0015QH-6Q for emacs-devel@gnu.org; Sun, 16 Jun 2019 23:52:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:I47jr/kQJuHnUt8BgSAdz38Ln+M= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:237750 Archived-At: > ;;; Faster in-line version zerop, normalized values only. > (defsubst Math-zerop (a) ; [P N] > (if (consp a) > (and (not (memq (car a) '(bigpos bigneg))) > (if (eq (car a) 'float) > (eq (nth 1 a) 0) > (math-zerop a))) > (eq a 0))) There's indeed an ordering issue with defsubst: when compiling a call to a defsubst such as Math-zerop, if Math-zerop is already compiled, then we inline its bytecode (this is done at the level of the "lapcode"), whereas if it's not compiled yet, then we inline the source code directly. Of course, to make things more interesting, this is only half-true: if the lexical-binding of the two files is different, then even if the function is not yet compiled, we don't inline its source code, instead we first compile it and then inline its bytecode (to avoid having to compile code that's a mix of lexical-binding and dynamic-binding). Arguably, we should drop support for inlining the source code and just always byte-compile the function before inlining it to avoid those side-effects. See byte-compile-inline-expand if you're interested in this. Stefan