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: Tue, 06 Nov 2018 11:29:41 -0500 Message-ID: References: <20181101175953.GC4504@ACM> <20181105105302.GA10520@ACM> <20181106151143.GB4030@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1541521701 22504 195.159.176.226 (6 Nov 2018 16:28:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Nov 2018 16:28:21 +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 Tue Nov 06 17:28:16 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 1gK4D9-0005kE-5q for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2018 17:28:15 +0100 Original-Received: from localhost ([::1]:41974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK4FF-0000Sc-PO for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2018 11:30:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK4F1-0000SM-6C for emacs-devel@gnu.org; Tue, 06 Nov 2018 11:30:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gK4Er-0000nM-Hc for emacs-devel@gnu.org; Tue, 06 Nov 2018 11:30:11 -0500 Original-Received: from alt22.smtp-out.videotron.ca ([70.80.0.73]:49473) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gK4Eq-0008Sk-2S for emacs-devel@gnu.org; Tue, 06 Nov 2018 11:30:00 -0500 Original-Received: from fmsmemgm.homelinux.net ([23.233.195.134]) by Videotron with SMTP id K4EXgffTIELtdK4EYgm8w6; Tue, 06 Nov 2018 11:29:43 -0500 X-Authority-Analysis: v=2.3 cv=atGc9xRV c=1 sm=1 tr=0 a=xXJ578j8WyTliCxld3/pTA==:117 a=xXJ578j8WyTliCxld3/pTA==:17 a=JHtHm7312UAA:10 a=vMjp4MXk8_B0HbLQIm4A:9 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id B5747AE145; Tue, 6 Nov 2018 11:29:41 -0500 (EST) In-Reply-To: <20181106151143.GB4030@ACM> (Alan Mackenzie's message of "Tue, 6 Nov 2018 15:11:43 +0000") X-CMAE-Envelope: MS4wfMW4UAscnNVDwEDm4GH7KPI9Fb+lEaLREdLqMPLfE6fniWCQujYCbQzmdBwvZeEIbcFzRZrZVAxatYWGasOoDvaHVyHDOmPMqAW36Wp+ZkS5kekZjmoM dkFefBG5e9FneN5+HBfNILTHVj3dCeuX+0PqMiEOaCXdupZFW8R1b9FVNuSk4RduF4e+cOQHPaW6p3l6H+8PaKLHgiPZRvwRlKhxXf5bsRliomYuwb5WFPW3 Oeohq8p3y5oIrklE0EakDQ== X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 70.80.0.73 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:231042 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... You may find it acceptable, but I don't, mostly because I know fundamentally it's not needed: it's only introduced for short/medium term convenience (to avoid having to rewrite a lot of code). And I can't see how we'll be able to get rid of it in the long run (gradually or not). So in the long run it's a bad option. > Many of the original forms produced by the reader survive these > transformations. Yeah, that's why I thought of using a hash-table. > I've tried 2., and given up on it: everywhere in the compiler where FORM > is transformed to NEWFORM, a copy of a hash has to be created for > NEWFORM. 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. > Also, there's no convenient key for recording the hash of an > occurence of a symbol (such as `if'). Ah, right, I keep forgetting this detail. Yes, that's a major downer. > 3. is what I'm proposing, I think. Yes [ sorry, you had to guess; I thought it was clear enough]. > The motivating thing here is that the rest of the system can handle > NEW-SPECIAL-OBJECT and get the same result it would have from OBJECT. > Hence the use of Lisp_Type 1, or possibly a new pseudovector type. How 'bout we don't try to add location to all objects, but only to some specific objects? E.g. only cons-cells? We could add a new "big cons-cell" type which shares the same tag, and just adds additional info after the end of the normal cons-cell (cons-cell would either be allocated from small_cons_blocks or big_cons_blocks, so you'd have to look at the enclosing cons_block to determine which kind of cons-cell you have). So normal code is not slowed down at all (except I guess for the GC which will be marginally slower). Stefan