From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: master b0ba0d42b0f: * src/lisp.h (EQ): Improve generated code. Date: Fri, 29 Nov 2024 03:21:01 -0500 Message-ID: References: <173279015204.1017853.4020802222494409378@vcs3.savannah.gnu.org> <20241128103552.86CC34F4FDB@vcs3.savannah.gnu.org> <8BCABD6D-6605-438C-A62D-B7DA42D07AD4@gmail.com> <867c8ncdx4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25986"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Mattias =?utf-8?Q?Engdeg=C3=A5rd?= , pipcet@protonmail.com, emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 29 09:22:09 2024 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 1tGwGP-0006VN-DS for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Nov 2024 09:22:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tGwFf-00065f-6V; Fri, 29 Nov 2024 03:21:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tGwFd-00065T-Fm for emacs-devel@gnu.org; Fri, 29 Nov 2024 03:21:21 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tGwFd-0001VJ-2p; Fri, 29 Nov 2024 03:21:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=DjfCgVkjFcuhCun4xYoHYTwW2vHvd8+rpqicoXm+vRk=; b=C/3FjgLwU6klgKjjW1K4 ZZGCqjytkvmPwjagyXnCorb+tI+fESev6EDY+CAIpYmyyzbdEAteXcpOY2Fm5EhjW4VNxE2JaIExo ktL2+UH0bX2L/YrR63/XPG/iKUwCKnNxhK7789F0VXR5CSc25AYqhZ7uF7S/jl/AKfovCT6bm4AYX 3pgP3NvdUagWH5pXBKCTOdUvxH/lBzAhXTAVlRzpFZMEI3dNXnVhV//PLhghT6l6ALtC/1VMCUtdy BeNTbHMWO0AW063boBlzsdMffO5jReDXurwSfbANRGTiwaLXoCFp3e5rVk9exUUAbAYt+NiNIumJr 1F4pPv7+R+h25Q==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1tGwFT-00061a-V9; Fri, 29 Nov 2024 03:21:20 -0500 In-Reply-To: (Stefan Kangas's message of "Thu, 28 Nov 2024 14:46:55 -0800") 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325849 Archived-At: Stefan Kangas writes: > Eli Zaretskii writes: > >>> From: Mattias Engdeg=C3=A5rd >>> Date: Thu, 28 Nov 2024 18:53:46 +0100 >>> Cc: Andrea Corallo , >>> Emacs Devel >>> >>> We should probably define some variant of likely/unlikely because >>> those cover most needs of __builtin_expect, rather than using it >>> directly. Then portability wouldn't be a problem. >> >> Portability is already not a problem, so I see no need for inventing >> new macros for this purpose. > > Right, since this is already done for us by Gnulib. But the other > reason to having such macros is readability. > > To be clear, the proposed macros would look something like this (copied > here from the Linux kernel): > > #define likely(x) __builtin_expect(!!(x), 1) > #define unlikely(x) __builtin_expect(!!(x), 0) > > Andrea's code would then read like so: > > - return BASE_EQ ((__builtin_expect (symbols_with_pos_enabled, false) > + return BASE_EQ ((unlikely (symbols_with_pos_enabled) Hi Stefan, I think I'm with Eli in suggesting we should just use __builtin_expect. Yes it reads a little longer but: 1- We define a layer of macros less 2- It's to me still very readable 3- In my mind introducing ad-hoc macros might encourage developers using them, while I think developers should refrain using them unless they really know what they are doing. IOW annotating branchs should be the rare exception rather than the rule, and for these rare cases __builtin_expect is IMO fine. Andrea