From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Gramiak Newsgroups: gmane.emacs.devel Subject: Re: Using __builtin_expect (likely/unlikely macros) Date: Fri, 19 Apr 2019 07:45:18 -0600 Message-ID: <87tveu85xt.fsf@gmail.com> References: <87a7gst973.fsf@gmail.com> <875zrgt12q.fsf@gmail.com> <6919a4c8-df76-ea1e-34db-1fa62a360e5a@cs.ucla.edu> <87h8aykdod.fsf@gmail.com> <4fa7885e-8c66-c7c4-ff71-a013505863af@cs.ucla.edu> <2dfb837d-989d-c736-b6e6-b20c0e940596@cs.ucla.edu> <87o956c4n4.fsf@gmail.com> <1fbd2fca-18f0-0a90-7a45-58419a9e11ee@cs.ucla.edu> <1555450070.23658.4@yandex.ru> <66b74701-012a-902e-4a5b-6bc30efa87c0@cs.ucla.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="190304"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: emacs-devel@gnu.org, Stefan Monnier , Konstantin Kharlamov To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 19 15:46:05 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hHTq7-000nG0-Ui for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2019 15:46:04 +0200 Original-Received: from localhost ([127.0.0.1]:56836 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHTq6-0001qL-Tk for ged-emacs-devel@m.gmane.org; Fri, 19 Apr 2019 09:46:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHTpU-0001lx-2W for emacs-devel@gnu.org; Fri, 19 Apr 2019 09:45:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHTpS-0003jA-Bt for emacs-devel@gnu.org; Fri, 19 Apr 2019 09:45:23 -0400 Original-Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]:46074) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hHTpS-0003f4-3r for emacs-devel@gnu.org; Fri, 19 Apr 2019 09:45:22 -0400 Original-Received: by mail-pf1-x42b.google.com with SMTP id e24so2592110pfi.12 for ; Fri, 19 Apr 2019 06:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=FQFhD35Va5NitcVcCl2x64NpFV3tXThSUHQbMciruEU=; b=fZL/5kMsTRnRTTeZC47s4b2+SQyLCKrB0Ti9KA3X5oJND7YjRjJtuL8/SJ8WvK5Ena kXe5Zz0op5zItK6DzboFbMAnS+tqp4o7RoO1dJsYI5Z2VfUMI2SMo5mQm+WdCmD79Szu HAa9U6XGgXSFlDoXC1wFNowgazTKe5nnbPWpcrEyHuoTkfdN96WG3qHBe0xVpASBAxBk oCZAeGweo4pOGMH5JX6LGbN0xEROdW3oiWFxzHi70yGmE/J+RnFLaXlzZ1sIPR56C1MF StmjBj0FdV10rEsJXjDELAAA2ZoXmSo6UOcs+lmkLeYuOar9HRFJJTiYkO5FWhIO8Alw nvgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=FQFhD35Va5NitcVcCl2x64NpFV3tXThSUHQbMciruEU=; b=sT/V2kuQxnIHdmgnGCKtrioGvA7qtif4hfgxMbSDtOdDUqgEv8I9ycpjwPcPL3yT1v 6576tImJwMP4PiqIgWVGtm+va6wdI2Kqj1SgoP8+AZGPj6N4X/YM2xgI/CGkTWVhUNZU 5m79W1HyMkmn710z9M/OcENoVtmt3vrzS/dnjczlrGPAG+c1U1+YZ47BjuyTPMW1N60Y Okhv4BZi8tU69vE66CFblWwuWC5BRnc43nV4JJ75IOeMtzV+/CBnlMvlk9EaBasxbhkh SmNd3V7tiYGbjE1ivqjOxS7mICtJJAPvIh+q/GYpSKCjWBZmBzho75OwHL6m4cw7iHur W8bA== X-Gm-Message-State: APjAAAWgMZOn6wo6MmmD0m1ITqZqUy9UW0U95jJBLHNq0DRR6Aj/OUpg XzgLlZQ7UzCMCezBEoFEkSmOfYzl X-Google-Smtp-Source: APXvYqxNHRQk7lsE3sdxC5PigaHDYFYWee3ycrnvVVranCnGrW0etkM3r24F46m0cnxvfxpBV74H4Q== X-Received: by 2002:a63:a18:: with SMTP id 24mr3217902pgk.332.1555681520621; Fri, 19 Apr 2019 06:45:20 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id j12sm6463109pgg.79.2019.04.19.06.45.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 19 Apr 2019 06:45:19 -0700 (PDT) In-Reply-To: <66b74701-012a-902e-4a5b-6bc30efa87c0@cs.ucla.edu> (Paul Eggert's message of "Thu, 18 Apr 2019 01:25:31 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::42b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:235656 Archived-At: --=-=-= Content-Type: text/plain Paul Eggert writes: > Konstantin Kharlamov wrote: >> I was told that e.g. "cold" attribute can sometimes produce unbearably slow >> code https://gcc.gnu.org/ml/gcc-help/2019-01/msg00035.html > > Although cold functions can be slow, it appears that overall it's a win for > Emacs to mark _Noreturn error function declarations as cold: on my platform, > 'make compile-always' ran about 1.3% faster. So I installed the attached patch > into master. Thanks. What do you think about marking a few bytecode cases as cold/unused? I've attached a diff below that does that. Does it make a difference for you on your setup? It seems to slow Emacs down a slight bit for me, but I was hoping you might know why it would do so. Since the newly cold attributes should be unused, is this perhaps a GCC bug? > This patch also adds a convenience macro AVOID for the now-common pattern > '_Noreturn ATTRIBUTE_COLD void'. I'm not sure about the name. If I wasn't part of this discussion I might have thought AVOID meant that one should avoid usage of the procedure in new code. Not a big deal, of course. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=cold.diff Content-Description: cold attributes diff --git a/src/bytecode.c b/src/bytecode.c index 40977799bf..17c4716fe0 100644 --- a/src/bytecode.c +++ b/src/bytecode.c @@ -656,6 +656,7 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth, CASE (Bunbind_all): /* Obsolete. Never used. */ /* To unbind back to the beginning of this frame. Not used yet, but will be needed for tail-recursion elimination. */ + __attribute__((cold, unused)); unbind_to (count, Qnil); NEXT; @@ -749,6 +750,7 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth, NEXT; CASE (Bsave_window_excursion): /* Obsolete since 24.1. */ + ATTRIBUTE_COLD; { ptrdiff_t count1 = SPECPDL_INDEX (); record_unwind_protect (restore_window_configuration, @@ -808,6 +810,7 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth, } CASE (Bcondition_case): /* Obsolete since 24.4. */ + ATTRIBUTE_COLD; { Lisp_Object handlers = POP, body = POP; TOP = internal_lisp_condition_case (TOP, body, handlers); @@ -815,12 +818,14 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth, } CASE (Btemp_output_buffer_setup): /* Obsolete since 24.1. */ + ATTRIBUTE_COLD; CHECK_STRING (TOP); temp_output_buffer_setup (SSDATA (TOP)); TOP = Vstandard_output; NEXT; CASE (Btemp_output_buffer_show): /* Obsolete since 24.1. */ + ATTRIBUTE_COLD; { Lisp_Object v1 = POP; temp_output_buffer_show (TOP); @@ -1138,6 +1143,7 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth, NEXT; CASE (Binteractive_p): /* Obsolete since 24.1. */ + ATTRIBUTE_COLD; PUSH (call0 (intern ("interactive-p"))); NEXT; @@ -1342,6 +1348,7 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth, /* Actually this is Bstack_ref with offset 0, but we use Bdup for that instead. */ /* CASE (Bstack_ref): */ + ATTRIBUTE_COLD; error ("Invalid byte opcode: op=%d, ptr=%"pD"d", op, pc - 1 - bytestr_data); --=-=-=--