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

On 4/16/26 12:19 PM, Stavros Macrakis wrote:

> 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.
Perhaps, but I rather like to know what actually happens. If it’s some 
random vague meaning of “space”, which isn’t actually defined, AFAICT, 
it’s a bit meaningless. It’s nice to know if I set space to 0, things 
will be inlined if it makes sense, and space 3 means it won’t, usually.
>
> As shown in this example, speed and space optimization aren't 
> necessarily contradictory.

Perhaps in this short example. It’s not so clear how this all works out 
in larger functions. AFAIK, no one is counting code size to decide 
space. It’s a much more granular than that. As you show inlining doesn’t 
always make the code size larger. But I think when that decision is 
made, the compiler doesn’t know how much code space is actually used.

Anyway, this is no longer about Maxima, per se.

>
>
> 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;
>
&#8203;

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