bug: EQUAL optimization is too agressive

[Roman Marynchak]

Consider this session in REPL:

[roman@myhost ~]$ sbcl
This is SBCL 1.0.46.10, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (declaim (optimize (debug 3) (speed 0) (safety 3)))

* (defun foo ()
    (equal (list a b c) (make-array 9)))

; in: LAMBDA NIL
; (LIST A B C)
;
; caught WARNING:
; undefined variable: A
;
; caught WARNING:
; undefined variable: B
;
; caught WARNING:
; undefined variable: C
;
; compilation unit finished
; Undefined variables:
; A B C
; caught 3 WARNING conditions

FOO
* (foo)

NIL
* (sb-c::describe-compiler-policy)

  Basic qualities:
COMPILATION-SPEED = 1
DEBUG = 3
SAFETY = 3
SPACE = 1
SPEED = 0

I expect to see the error message about A, B and C being undefined. Instead, the call returns NIL even with the most liberal optimization policy. LW, CLISP and Clozure signal the error for this code.

[Roman Marynchak (roman-marynchak)]

Additional info: EQ and EQL have the same problem, but EQUALP works fine.

[Roman Marynchak (roman-marynchak)]

I suggest using SAFETY 3 as a barrier for such optimizations (do not guess anything about equality of the things based on their type). Do you think that other optimization policy is better to turn them on/off? Please share your opinion, in case you support the idea, I will add tests and supply a full patch instead of this diff.

Thank you.

[Nikodemus Siivola (nikodemus)]

The problem isn't really in the equality optimizations. It's fine for the compiler to optimize them away.

What's wrong is that the compiler is also optimizing away references to the global variables -- which can be unbound.

If you look at IR1-CONVERT-VAR, you will see that it is already special casing for this eventuality when the value is unused. But as you discovered, being used is not sufficient as the destination may be deleted later. We should to convert all global variables that are not ALWAYS-BOUND using SYMBOL-VALUE/SYMBOL-GLOBAL-VALUE.

[Roman Marynchak (roman-marynchak)]

Another patch, based on the above advices.

Note that it makes one of stepper tests unhappy with SYMBOL-VALUE, but the workaround is present in the patch itself.

The last question to answer is whether there is performance penalty after the patch is applied.

[Nikodemus Siivola (nikodemus)]

Thank you. Fix based on your patch committed as 1.0.48.14: STEP-FORM-P needed adjustment for consistent treatment of global symbol references.