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

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