From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Changes in GC and in pure space Date: Wed, 4 Sep 2019 12:15:40 -0700 Organization: UCLA Computer Science Department 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> <878sr3rjva.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="216687"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: emacs-devel@gnu.org To: =?UTF-8?Q?=c3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 04 21:16:26 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 1i5alU-000uC7-Qr for ged-emacs-devel@m.gmane.org; Wed, 04 Sep 2019 21:16:24 +0200 Original-Received: from localhost ([::1]:36534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i5alS-0001Gd-TU for ged-emacs-devel@m.gmane.org; Wed, 04 Sep 2019 15:16:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37808) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i5akr-0001GF-2X for emacs-devel@gnu.org; Wed, 04 Sep 2019 15:15:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i5akp-00015n-E7 for emacs-devel@gnu.org; Wed, 04 Sep 2019 15:15:44 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48724) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i5akp-00013M-8I for emacs-devel@gnu.org; Wed, 04 Sep 2019 15:15:43 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E737A160057; Wed, 4 Sep 2019 12:15:41 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id aQBw6P12QXAI; Wed, 4 Sep 2019 12:15:41 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 396D91600FC; Wed, 4 Sep 2019 12:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VXiOrqcIBV3F; Wed, 4 Sep 2019 12:15:41 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 15727160057; Wed, 4 Sep 2019 12:15:41 -0700 (PDT) In-Reply-To: <878sr3rjva.fsf@telefonica.net> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:239848 Archived-At: =C3=93scar Fuentes wrote: > At least in the C++ world, `inline' is used for putting function > definitions on headers, not for inlining. >=20 > There is a consensus from many years ago that the compiler is expected > to do the right thing wrt inlining irrespectively of the presence or > ausence of the keyword Things are a bit different in C. In C, the consensus you mention holds fo= r=20 'static inline' (where the 'inline' is typically just a noise word nowada= ys),=20 but it does not hold for the plain 'inline' functions that we're talking = about=20 because C requires that if one compilation unit defines a plain 'inline'=20 function, then exactly one other compilation unit must define that functi= on as=20 'extern inline'. Emacs rarely uses 'static inline', due to the consensus that you mention.= In the=20 few exceptions where Emacs does use 'static inline', I vaguely recall the= re=20 being performance advantages when compiled by GCC in typical platforms, a= s GCC=20 does not ignore the 'inline' in these exceptional situations.