From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Thoughts on getting correct line numbers in the byte compiler's warning messages Date: Wed, 07 Nov 2018 12:25:15 -0500 Message-ID: References: <20181101175953.GC4504@ACM> <20181105105302.GA10520@ACM> <20181106151143.GB4030@ACM> <20181107170036.GA4934@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1541611495 5992 195.159.176.226 (7 Nov 2018 17:24:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Nov 2018 17:24:55 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 07 18:24:51 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gKRZS-0001R7-KH for ged-emacs-devel@m.gmane.org; Wed, 07 Nov 2018 18:24:50 +0100 Original-Received: from localhost ([::1]:49479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKRbY-0005ED-QG for ged-emacs-devel@m.gmane.org; Wed, 07 Nov 2018 12:27:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKRZz-0004eF-Bt for emacs-devel@gnu.org; Wed, 07 Nov 2018 12:25:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKRZt-0007im-J1 for emacs-devel@gnu.org; Wed, 07 Nov 2018 12:25:22 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:40757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKRZt-0007hg-C8 for emacs-devel@gnu.org; Wed, 07 Nov 2018 12:25:17 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id wA7HPFxR014178; Wed, 7 Nov 2018 12:25:15 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 719426A55C; Wed, 7 Nov 2018 12:25:15 -0500 (EST) In-Reply-To: <20181107170036.GA4934@ACM> (Alan Mackenzie's message of "Wed, 7 Nov 2018 17:00:36 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6413=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6413> : inlines <6957> : streams <1803592> : uri <2745812> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:231051 Archived-At: >> > I timed a bootstrap, unoptimised GCC, with an extra tag check and >> > storage to a global variable inserted into XFIXNUM. (Currently there is >> > no such check there). The slowdown was around 1.3% > >> That accumulates for every data type, and it increases code size, >> reduces cache hit rate... > > No, it applies mainly to FIXNUM, because XFIXNUM doesn't already check > the Lisp_Type. Other object types already perform this check, so while I'm not sure why you say that. XCONS/XSYMBOL don't perform the check either (unless you compile with debug-checks, of course, but that's not the important case). > Yes, it may be a bad option, but possibly less bad than the other bad > options we have. There's indeed a pretty good set of bad options at hand. Not sure which one will suck less. > cconv.el would need to be entirely rewritten if we stick to the hash > table approach. It wouldn't survive anything like unscathed even in an > "extended Lisp Object" solution. It's "only" the cconv-convert part of cconv.el that will need changes, but yes, one way or another it will need to be changed to preserve the location info. > Maybe it would be possible to defer cconv.el processing till after macro > expansion and byte-opt.el stuff. Would this do any good? It's already done after macro expansion (but before byte-opt). I don't think it moving it would help. > The only vague idea I have for saving this, and I don't like it one bit, > is somehow to redefine \` (and possibly \,) in such a way that it would > somehow copy the source position from the original list to the result. Define "original list" ;-) >> Same with your new scheme: everywhere where a "big cons-cell" is >> transformed, by a macro you'll get a "small cons-cell". >> That's a constant of all options, AFAICT. > The "extended" symbols would survive. That is a big plus. Indeed symbols are usually preserved un-touched. > I've been through these sort of thoughts. That idea would be less > effective than the "extended object", since it would only work with > conses, but might be less disruptive. But why should it only work with > conses? No particular reason at first. > Why not with symbols, too? Reproducing this idea for other types is not always that easy or useful: - for pseudo-vectors the variable size aspect makes it harder to handle (tho not impossible). OTOH we could probably use a bit in the header and thus avoid the need to place those extended objects in their own blocks. - for symbols the extra info is "per symbol occurrence" rather than "per symbol", so we can't add this info directly to the symbol (i.e. the same reason the hash-table approach doesn't work for symbols). So we'd really want a completely separate object which then points to the underlying symbol object. But yes, we could introduce a new symbol-occurrence object, along the lines you originally suggested but only for symbols (thus reducing the performance cost). -- Stefan