GNU bug report logs - #42147
28.0.50; pure vs side-effect-free, missing optimizations?

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Andrea Corallo <andrea_corallo <at> yahoo.it>, 42147 <at> debbugs.gnu.org
Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?
Date: Fri, 3 Jul 2020 20:35:34 +0200

3 juli 2020 kl. 15.11 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> 
>> Fortunately modern compilers generate SSE code by default, only passing
>> return values on the x87 stack as per the x86 ABI (which causes no
>> harm). This reduces an already tiny risk to nil. We could add an elaborate
>> configure or run-time test and admonishments to the installation
>> instructions but frankly we have better use of our time. I suggest we
>> replace byte-opt--portable-numberp with numberp (or nothing at all,
>> depending on where it occurs) and be done with it.
> 
> Agreed,

Thanks -- patch attached. Some expressions will still not be constant-folded entirely; for example

(byte-optimize-form '(+ #x100000000000000 1 1))
=> (+ 72057594037927936 1 1)

This will be fixed automatically by marking + as pure; the same should be done for the other arithmetic functions.

By the way, is it a bug or a feature that calls to pure functions with constant but invalid arguments raise an error at compile-time? For example:

(disassemble (lambda () (if nil (regexp-quote nil))))

will raise an error despite none would be generated at run time if this function were interpreted.
It's easy to suppress those errors, but I see how they can be useful in practice.

Previous Next

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