如何让SBCL优化掉对FDEFINITION的潜在调用？是否具备可行性？

首先来拆解这个编译器提示的核心含义：

note: unable to
optimize away possible call to FDEFINITION at runtime
because:
FUNCTION is not known to be a function —

SBCL的这个提示是在直白地告诉你：它没办法确定传入execute-parallel的function参数一定是一个函数对象——毕竟Lisp允许传入符号（比如函数名）来间接调用函数，这时候就需要运行时通过FDEFINITION去查找对应的函数实体。正因为存在这种不确定性，编译器没法安全地把这个潜在的FDEFINITION调用优化掉。

能不能优化掉这个潜在调用？当然可行！ #

解决方法非常直接：给function参数添加明确的类型声明，彻底消除编译器的不确定性，告诉它这个参数就是一个可以直接调用的函数对象。

你可以修改execute-parallel函数的声明部分，补充function的类型约束：

#+sb-thread
(defun execute-parallel (start end function)
  (declare (type int31 start end)
           ;; 明确function是接受两个int31参数的函数（返回值用*表示任意类型）
           (type (function (int31 int31) *) function))
  (let* ((num-threads 4))
    (loop with step = (truncate (- end start) num-threads)
          for index from start below end by step
          collecting (let ((start index)
                          (end (min end (+ index step))))
                      (sb-thread:make-thread
                       (lambda () (funcall function start end))))
          into threads
          finally (mapcar #'sb-thread:join-thread threads))))

如果不需要限定参数类型，至少可以声明它是通用的函数类型：

(declare (type function function))

添加这个声明后，编译器就确定function必然是一个可直接调用的函数对象，不需要再保留运行时查找FDEFINITION的逻辑，自然就能优化掉这个潜在调用了。

这个提示是说明还是优化机会？ #

它两者都是：

• 首先是状态说明：清晰告知你当前编译器无法完成某类优化的具体原因；
• 同时也是明确的优化机会：只要你消除了编译器的不确定性（比如添加类型声明），它就能立刻完成对应的优化，生成更高效的机器码。

内容的提问来源于stack exchange，提问作者igouy