From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Correct line/column numbers in byte compiler messages Date: Sat, 21 Mar 2020 23:39:52 +0000 Message-ID: References: <20200319203449.GA4180@ACM> <20200320191846.GA5255@ACM> <20200321153041.GA7805@ACM> <20200321201954.GB7805@ACM> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="114878"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Rocky Bernstein , Stefan Monnier , emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 22 00:40:34 2020 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 1jFnjF-000Tnb-IQ for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Mar 2020 00:40:33 +0100 Original-Received: from localhost ([::1]:41886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFnjE-0004KO-Jo for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Mar 2020 19:40:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38227) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFnif-0003vZ-7M for emacs-devel@gnu.org; Sat, 21 Mar 2020 19:39:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jFnid-0004DQ-Vo for emacs-devel@gnu.org; Sat, 21 Mar 2020 19:39:57 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:55918) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jFnid-0004Ar-LS; Sat, 21 Mar 2020 19:39:55 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 02LNdq7H023568 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 21 Mar 2020 23:39:52 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02LNdqCL022567; Sat, 21 Mar 2020 23:39:52 GMT In-Reply-To: (Andrea Corallo's message of "Sat, 21 Mar 2020 21:08:10 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 205.166.94.20 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245653 Archived-At: --=-=-= Content-Type: text/plain Andrea Corallo writes: > Alan Mackenzie writes: > >> >> I'm seeing 19.4s vs. 22.2s, which is around 15% difference. :-( > > I get 19.30 sec against 16.65 that is 15% difference here too. This is > extremely interesting and would be worth profiling. > > I bet on the GC for this! (Note I'm notoriously wrong when speculating > on benchmarks :) At this point the evening has been dedicated to this. Apparently part of the issue is that GCC is quite conservative on the inline policy and because the more complex condition in EQ decide not to inline this (at least I see this is not done always). This is true for EQ and some of his friends defined in lisp.h. Part of the cost is not the branch itself but the additional procedure activations. Pushing a little more into inlining GCC with the raw attached patch I got it down on the mackenzie-test to 18.17s that is still/just 9% out. The remaining part is probably a little harder to investigate but I still suspect more of a 'side reasons' than a fundamental one. I suggest we try the fine tuning when rebased on 28 if not too hard. Regards Andrea -- akrl@sdf.org --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=tmp.patch diff --git a/src/lisp.h b/src/lisp.h index a22043026a..d0c56d7bbb 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -394,8 +394,12 @@ typedef EMACS_INT Lisp_Word; /* #define lisp_h_EQ(x, y) (XLI (x) == XLI (y)) */ /* verify (NIL_IS_ZERO) */ + +#define SYMBOLS_WITH_POS_ENABLED \ + __builtin_expect(symbols_with_pos_enabled, 0) + #define lisp_h_EQ(x, y) ((XLI ((x)) == XLI ((y))) \ - || (symbols_with_pos_enabled \ + || (SYMBOLS_WITH_POS_ENABLED \ && (SYMBOL_WITH_POS_P ((x)) \ ? BARE_SYMBOL_P ((y)) \ ? (XSYMBOL_WITH_POS((x)))->sym == (y) \ @@ -424,7 +428,7 @@ typedef EMACS_INT Lisp_Word; #define lisp_h_BARE_SYMBOL_P(x) TAGGEDP ((x), Lisp_Symbol) /* verify (NIL_IS_ZERO) */ #define lisp_h_SYMBOLP(x) ((BARE_SYMBOL_P ((x)) || \ - (symbols_with_pos_enabled && (SYMBOL_WITH_POS_P ((x)))))) + (SYMBOLS_WITH_POS_ENABLED && (SYMBOL_WITH_POS_P ((x)))))) #define lisp_h_TAGGEDP(a, tag) \ (! (((unsigned) (XLI (a) >> (USE_LSB_TAG ? 0 : VALBITS)) \ - (unsigned) (tag)) \ @@ -463,7 +467,7 @@ typedef EMACS_INT Lisp_Word; /* verify (NIL_IS_ZERO) */ # define lisp_h_XSYMBOL(a) \ (eassert (SYMBOLP ((a))), \ - (!symbols_with_pos_enabled \ + (!SYMBOLS_WITH_POS_ENABLED \ ? (XBARE_SYMBOL ((a))) \ : (BARE_SYMBOL_P ((a))) \ ? (XBARE_SYMBOL ((a))) \ @@ -1137,38 +1141,38 @@ enum More_Lisp_Bits #define MOST_POSITIVE_FIXNUM (EMACS_INT_MAX >> INTTYPEBITS) #define MOST_NEGATIVE_FIXNUM (-1 - MOST_POSITIVE_FIXNUM) -INLINE bool +INLINE bool __attribute__ ((always_inline)) PSEUDOVECTORP (Lisp_Object a, int code) { return lisp_h_PSEUDOVECTORP (a, code); } -INLINE bool +INLINE bool __attribute__ ((always_inline)) (BARE_SYMBOL_P) (Lisp_Object x) { return lisp_h_BARE_SYMBOL_P (x); } -INLINE bool +INLINE bool __attribute__ ((always_inline)) (SYMBOL_WITH_POS_P) (Lisp_Object x) { return lisp_h_SYMBOL_WITH_POS_P (x); } -INLINE bool +INLINE bool __attribute__ ((always_inline)) (SYMBOLP) (Lisp_Object x) { return lisp_h_SYMBOLP (x); } -INLINE struct Lisp_Symbol_With_Pos * +INLINE struct Lisp_Symbol_With_Pos * __attribute__ ((always_inline)) XSYMBOL_WITH_POS (Lisp_Object a) { eassert (SYMBOL_WITH_POS_P (a)); return XUNTAG (a, Lisp_Vectorlike, struct Lisp_Symbol_With_Pos); } -INLINE struct Lisp_Symbol * ATTRIBUTE_NO_SANITIZE_UNDEFINED +INLINE struct Lisp_Symbol * __attribute__ ((always_inline)) ATTRIBUTE_NO_SANITIZE_UNDEFINED (XBARE_SYMBOL) (Lisp_Object a) { #if USE_LSB_TAG @@ -1186,7 +1190,7 @@ INLINE struct Lisp_Symbol * ATTRIBUTE_NO_SANITIZE_UNDEFINED #endif } -INLINE struct Lisp_Symbol * ATTRIBUTE_NO_SANITIZE_UNDEFINED +INLINE struct Lisp_Symbol * __attribute__ ((always_inline)) ATTRIBUTE_NO_SANITIZE_UNDEFINED (XSYMBOL) (Lisp_Object a) { return lisp_h_XSYMBOL (a); @@ -1336,7 +1340,7 @@ INLINE bool /* Return true if X and Y are the same object, reckoning a symbol with position as being the same as the bare symbol. */ -INLINE bool +inline bool __attribute__ ((always_inline)) (EQ) (Lisp_Object x, Lisp_Object y) { return lisp_h_EQ (x, y); @@ -2690,7 +2694,7 @@ XOVERLAY (Lisp_Object a) return XUNTAG (a, Lisp_Vectorlike, struct Lisp_Overlay); } -INLINE Lisp_Object +INLINE Lisp_Object __attribute__ ((always_inline)) SYMBOL_WITH_POS_SYM (Lisp_Object a) { if (!SYMBOL_WITH_POS_P (a)) @@ -2698,7 +2702,7 @@ SYMBOL_WITH_POS_SYM (Lisp_Object a) return XSYMBOL_WITH_POS (a)->sym; } -INLINE Lisp_Object +INLINE Lisp_Object __attribute__ ((always_inline)) SYMBOL_WITH_POS_POS (Lisp_Object a) { if (!SYMBOL_WITH_POS_P (a)) --=-=-=--