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: Changes in GC and in pure space Date: Wed, 04 Sep 2019 13:45:48 -0400 Message-ID: References: <20190721193221.1964.53182@vcs0.savannah.gnu.org> <20190721193222.8C19E20BE2@vcs0.savannah.gnu.org> <83blxmqfkq.fsf@gnu.org> <9568ca7d-854f-1971-bbe8-03ba8c64af42@cs.ucla.edu> <83o9006rol.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77111"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Paul Eggert , dancol@dancol.org, pipcet@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 04 19:47:03 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 1i5ZN0-000Jwt-Rm for ged-emacs-devel@m.gmane.org; Wed, 04 Sep 2019 19:47:03 +0200 Original-Received: from localhost ([::1]:36086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i5ZMz-0000Zb-P1 for ged-emacs-devel@m.gmane.org; Wed, 04 Sep 2019 13:47:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53373) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i5ZM3-0000ZV-3b for emacs-devel@gnu.org; Wed, 04 Sep 2019 13:46:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i5ZM0-00085z-AX for emacs-devel@gnu.org; Wed, 04 Sep 2019 13:46:01 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57930) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i5ZLu-00084Y-L9; Wed, 04 Sep 2019 13:45:55 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25E88100ECB; Wed, 4 Sep 2019 13:45:52 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 93934100B39; Wed, 4 Sep 2019 13:45:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1567619150; bh=ZCEDIBtXsfBzMQppU1ATiRnO4JuOcY4v3u5fRqe+EZU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nK0bd945PP6l5dtxaWEapctgnRNAjeiOkEDWSrSpqbnEfOgDrNwEksB1r+2L5ZrwV 265Lu+Aid9qoxFJWWHl65ItANMqibl6MLOvAs6mK4yAdCOk2jnOjPU4QHmrJJhhGmr I/HaNQPfQ2sh6bxthZSvgRvmYAdvsgfm4riJtt3mxufurM414u+39sMlQnLIZWxJTM kFk4zBAYbYVctp8YHYDXpCpqUIRs2xYhDHOWa/9cJ85ZqLMRb2eFnVYdE6i3Qm7gOs ukiaepQ/a8i3TXSGCEmyXXSz/XNbFYBP6ENV1uJLkU9OC+/z1KNSqoZAZlEaFru1P9 vG+dvrvIGJEcg== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7A376120272; Wed, 4 Sep 2019 13:45:50 -0400 (EDT) In-Reply-To: <83o9006rol.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 04 Sep 2019 17:51:06 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 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:239841 Archived-At: > How portable is "INLINE" (and if it's portable enough, why do we use a > macro for it)? If some platforms don't support it, and these macros > become non-inline functions, those platforms will be punished by this > kind of changes. I'm not sure if replacing INLINE with nothing at all would lead to much worse code. Obviously, in some cases it will, but the optimizer should generally still inline them anyway. > I FWIW, personally find the issue of confusion about macro argument > evaluation to be a very weak one as justification to get rid of macros > that needed approximately zero maintenance for many years. I don't find it terribly compelling either, although I have been bitten a few times. OTOH as functions, they tend to behave better in GDB. So overall, I think it's good to use functions rather than macros where both are applicable (just like in Elisp). Stefan