Re: SBCL tells me it is deleting unreachable code that is almost surely reachable

Yes, the SBCL documentation explicitly says
<https://www.sbcl.org/manual/#Declarations-as-Assertions:~:text=The%20value%20of%20space%20mostly%20influences%20the%20compiler%E2%80%99s%20decision%20whether%20to%20inline%20operations>
"The value of space mostly influences the compiler’s decision whether to
inline operations...".

But that really isn't in keeping with the CL definition of optimization
directives
<https://mr.gy/ansi-common-lisp/optimize.html#:~:text=Advises%20the%20compiler%20that%20each%20quality%20should%20be%20given%20attention>
"Advises the compiler that [the] *quality *should be given attention".

That is, the optimization directives are supposed to specify a *goal*, not
a *mechanism*. It should be up to the compiler to figure out how to meet
that goal.  The programmer shouldn't have to be second-guessing the
compiler.

As shown in this example, speed and space optimization aren't necessarily
contradictory.


On Thu, Apr 16, 2026 at 10:41 AM Raymond Toy <[email protected]> wrote:

> On 4/15/26 3:06 PM, Stavros Macrakis wrote:
>
> On Wed, Apr 15, 2026 at 4:07 PM Raymond Toy <[email protected]> wrote:
> ...
>
>> On 4/15/26 10:12 AM, Stavros Macrakis wrote:
>>
>> Looking at the generated code, I see that with *optimize speed:0 space:3*,
>> SBCL calls *member-eq*, even though that takes more space. Apparently it
>> uses an inaccurate heuristic to estimate space usage.
>>
>> Surely a simple function call to member-eq takes less space than inlining
>> 3 comparisons and branches
>>
>
> Sounds plausible, and presumably that's what the *space* heuristic is
> based on, but...
>
> Here's the test:
>
> (disassemble
>     (lambda (x)
>       (declare (optimize (space *X*) (speed *Y*)))
>       (and (member x '(a b c)) t)))
>
> The *and *is so that we depend only on the boolean value, not the list
> value of *member: *for example, *(member 'b '(a b c))* returns *(b c)*,
> which then has to be tested to see whether it's* nil *in the function
> case, and in the inline case, each conditional has to return a different
> value.
>
> In SBCL:
> With speed=3, and space=0, it inlines, and compiles to 47 bytes.
> With speed=3, and space=3, it inlines, and compiles to 47 bytes.
> With speed=0 and space=0, it inlines, and compiles to 55 bytes.
> With speed=0 and space=3, it calls *member*, and compiles to 66 bytes.
>
> Interactions of these compilation properties is always complicated. Speed
> 3 and space 3 are somewhat contradictory. Speed 3 would generally imply
> inlining. Space 3 would say inlining is not preferred. I guess you’d need
> to read the manual to see how they interact. Or find the source code. The
> cmucl manual doesn’t say too much about this, and it’s hard to find how
> these properties interact.
> &#8203;
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss