GNU bug report logs - #65017
29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function

Previous Next

Full log

Message #74 received at 65017 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mattias.engdegard <at> gmail.com, 65017 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, eric.marsden <at> risk-engineering.org
Subject: Re: bug#65017: 29.1; Byte compiler interaction with cl-lib function
 objects, removes symbol-function
Date: Fri, 4 Aug 2023 14:16:22 +0000

Hello, Eli.

On Fri, Aug 04, 2023 at 08:35:30 +0300, Eli Zaretskii wrote:
> > Cc: acm <at> muc.de, 65017 <at> debbugs.gnu.org,
> >  Eric Marsden <eric.marsden <at> risk-engineering.org>
> > Date: Thu, 3 Aug 2023 21:10:56 +0000
> > From: Alan Mackenzie <acm <at> muc.de>
> > 
> > I think the cause is in internal_equal in src/fns.c, where the following
> > code appears:
> > 
> >   /* A symbol with position compares the contained symbol, and is
> >      `equal' to the corresponding ordinary symbol.  */
> >   if (SYMBOL_WITH_POS_P (o1))
> >     o1 = SYMBOL_WITH_POS_SYM (o1);
> >   if (SYMBOL_WITH_POS_P (o2))
> >     o2 = SYMBOL_WITH_POS_SYM (o2);
> > 
> > This piece of code converts symbols with positions to ordinary symbols
> > without first checking symbols-with-pos-enabled.  I think this is the
> > bug.
> > 
> > I will work on a patch to fix it (which shouldn't take long).

I have raised bug #65051 for this (which already contains a patch).

> Thanks, but when you have a solution in hand, please also check its
> effect on performance.  AFAIR, this part was tuned for optimal
> performance, back when symbols with positions were introduced; it
> would be a pity to lose performance due to fixing this bug, if that
> can be avoided.

I don't think we need worry, here.  In the generated code, in the normal
non-compilation scenario, two tests are being replaced by one test.

The current two tests are on variables which will already be in
registers, but they perform fairly involved bit twiddling.

The new test is a simple zero/non-zero test on a variable which, whilst
not yet in a register, will certainly be in the processor's cache.
Also, that variable will shortly be needed again, in the Lisp_Cons case.

I'll try a few timings, though.  I'll be surprised indeed if there're
any measurable differences.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.