EQL-specialized generic functions never memoize: every call is a full dispatch miss #1811

Activity

1. dg1sbg commented on Jul 31, 2026

   

   dg1sbg

   on Jul 31, 2026

   ContributorAuthor

   More actions

   Audited the remaining #.(find-class ...) sites in the kernel. A third one is dead, and this one is a correctness bug rather than a lost optimization.

   validate-superclass rejects AMOP-legal hierarchies

   class.lisp:171-181 uses read-time literals to permit a standard-class and a funcallable-standard-class to appear in each other's superclass chain. Both clauses evaluate false in the built image, so the mixed case is rejected:

   (defclass plain-sc () ((a :initform 1)))
   
   (defclass fsc-from-sc (plain-sc) () (:metaclass clos:funcallable-standard-class))
   ;; => Class #<STANDARD-CLASS PLAIN-SC> is not a valid superclass for
   ;;    #<FUNCALLABLE-STANDARD-CLASS FSC-FROM-SC>

   Called directly, both directions return NIL where T is expected:

   (clos:validate-superclass (find-class 'standard-generic-function)  ; funcallable-standard-class
                             (find-class 'plain-sc))                  ; standard-class     => NIL
   (clos:validate-superclass (find-class 'plain-sc)
                             (find-class 'standard-generic-function)) ; => NIL

   Full audit

   Site	Guard	Result
   miss.lisp:266	(eq (class-of gf) #.(find-class 'standard-generic-function))	dead
   svuc.lisp:21-23	(eq (class-of class) #.(find-class 'standard-class)) …	dead
   class.lisp:174-177	(eq c1 #.(find-class 'standard-class)) …	dead
   class.lisp:184	(eq superclass #.(find-class 't))	works
   class.lisp:307-309	(eq metaclass #.(find-class 'standard-class)) …	works
   generic.lisp:284	(eql spec #.(find-class 't))	works
   method.lisp:117-121	(class-prototype #.(find-class 'standard-generic-function))	works

   What the split is not

   Several plausible explanations are ruled out by the table:

   • Not per-class. #.(find-class 'standard-class) is dead at svuc.lisp:21 and at class.lisp:176, but works at class.lisp:307.
   • Not per-file. Within class.lisp, line 174-177 is dead while 184 and 307 work.
   • Not defun vs defmethod. Both groups contain both.
   • Not test-vs-value. The working method.lisp case uses the literal as a value, but the working class.lisp:307 and generic.lisp:284 cases are eq/eql tests.
   • Not class-of vs si::instance-class. The two dead class-of sites and the working instance-class site suggested this, but (eq (class-of c) (si::instance-class c)) is T for the classes involved.

   The only consistent observation remains the one in the issue body: recompiling the identical source at runtime produces working code, so the divergence is introduced at build time. Note the built-in class T works in both places it appears, while every dead site names a CLOS metaobject class — but class.lisp:307 is a counterexample to that being sufficient on its own.

   PR #1812 fixes the first two by switching to a runtime find-class. The validate-superclass case is left alone there pending a decision on whether to paper over each site individually or fix the underlying cause.
2. dg1sbg commented on Aug 1, 2026

   

   dg1sbg

   on Aug 1, 2026

   ContributorAuthor

   More actions

   Root cause found

   It is not specific to #. or to CLOS at all. (eq X <constant>) is folded to NIL whenever X has a declared CLOS class type and the constant is an instance of that type.

   The #.(find-class ...) guards were just the place it happened to bite: class-of is proclaimed (ftype (function (t) class) class-of) (cleavir/proclamations.lisp:269), so (eq (class-of x) #.<a class object>) has a class-typed operand and a constant-instance operand — exactly the broken shape.

   Minimal reproducer

   Compiled into the kernel (cross-clasp / native), then called:

   (defun probe-t   (x) (declare (type t x))              (eq x #.(find-class 'clos:funcallable-standard-class)))
   (defun probe-cls (x) (declare (type class x))          (eq x #.(find-class 'clos:funcallable-standard-class)))
   (defun probe-sc  (x) (declare (type standard-class x)) (eq x #.(find-class 'standard-class)))
   (defun probe-cof ()  (eq (class-of (find-class 'standard-generic-function))
                            #.(find-class 'clos:funcallable-standard-class)))

   form	result	expected
   (probe-t (find-class 'clos:funcallable-standard-class))	T	T
   (probe-cls (find-class 'clos:funcallable-standard-class))	NIL	T
   (probe-sc (find-class 'standard-class))	NIL	T
   (probe-cof)	NIL	T

   Declaring the argument t works. Declaring it class or standard-class — a strictly more precise, and correct, declaration — silently makes the comparison constant-NIL.

   Where

   src/lisp/kernel/cleavir/transform.lisp:406:

   ;;; If the types of the arguments are disjoint, EQ (and EQL) are false.
   (deftransform eq (((x t) (y t)) :argstype args)
     (with-transformer-types (x y) args
       (if (ctype:disjointp x y *clasp-system*)
           'nil
           (decline-transform "types not disjoint"))))

   and Ctype/other-functions.lisp:63:

   (defun disjointp (ct1 ct2 system)
     (bottom-p (conjoin/2 ct1 ct2 system) system))

   So conjoining a CLOS class ctype with a member/eql ctype whose element is a CLOS instance yields bottom, and disjointp reports disjoint. That is unsound: #<FUNCALLABLE-STANDARD-CLASS ...> is of type class, so the conjunction is the member type, not bottom. disjointp's docstring allows false negatives ("may return false even if the ctypes are disjoint"), but a false positive silently miscompiles code.

   Why it looked mysterious

   • Only the native/cross-clasp path is affected; the bytecode compiler does not run these transforms, so redefining the identical source at runtime always worked.
   • The literal really is eq to the live class — the constant is fine. Nothing is stale. The comparison is discarded before it ever runs.
   • Every dead guard routed through class-of; every working one did not (class.lisp:307 uses si::instance-class, which has no such proclamation, and works with the same literal in the same file).

   Scope

   Wider than the three guards in #1812. Any code of the form (eq x <literal instance>) where x is declared to a CLOS class type compiles to NIL — including user code. eql has the same transform immediately below and presumably the same exposure.

   I have not attempted a fix: the defect is in ctype conjunction/bottom-p for member types over CLOS instances, and guessing at Cleavir's type-inference invariants seemed more likely to cause harm than the documented bug. #1812 remains a correct workaround for the three kernel sites regardless of how this is resolved.