Comment 3 for bug 1187879

First off: These days I think many of stack allocation tests should be written using SB-INTROSPECT:ALLOCATION-INFORMATION to check if objects of interest are actually on stack or not.

Anyways, it looks to me like a regression -- unless it was always broken and just worked accidentally before...

(I would like to take a moment to apologise for the horrible names and lacking comments there.)

As far as I remember, the MAKE-NESTED-GOOD is supposed to be OK for stack allocation, whereas the SETF in MAKE-NESTED-BAD should prevent stack allocation. (Or at least stack allocation of the part that escapes via the SETF.)

I'm betting that the incredibly bogus error is the result MAKE-NESTED-BAD stack-allocating when it should not.

Just to clarify the point a bit further: when DX is requested we try to stack allocate as much as the nested structure as we can. Prior to the change that introduced this test nested structure constructors didn't stack allocate anything except the innermost structure.

This is the commit in question:

Author: Nikodemus Siivola <email address hidden>
Date: Fri Dec 12 13:05:23 2008 +0000

    1.0.23.38: fix bug 430 (stack alloc by nested defstruct constructors)

     * Mark lambdas introduced by the compiler as such, so that
       LAMBDA-SYSTEM-LAMBDA-P returns true for them.

     * Allow USE-GOOD-FOR-DX-P to inspect COMBINATIONs with CLAMBDA
       functionals: if the return value of the function always originates
       from a known DX-capable combination, and the arguments of the
       original combination are used only by the DX-capable combination,
       consider the original combination good for DX.

     * Allow USE-GOOD-FOR-DX-P to inspect REFs to LAMBDA-VARs: if the var
       is bound by a system lambda, has no other refs, is never set, gets
       its value from a single-value combination, and the LVAR it gets its
       value from is good for DX ... then the REF is good for DX as well.

     * HANDLE-NESTED-DYNAMIC-EXTENT-LVARS handles REFs as well by
       recursing on the lvar the REF gets its value from.

The important bits, IIRC, in the commit are DX-COMBINATION-P, and COMBINATION-ARGS-FLOW-CLEANLY-P. The SETF should cause the latter to say "no, they don't flow cleanly, so not OK to extend DX to arguments".

I'd start by winding history back to 6fd5fc37c44cc49ff0cb587022df4c881683a111 (first appearance of ALLOCATION-INFORMATION) and write a test that checks if things are allocated on stack when supposed to, and on heap when supposed to.

If nested structure DX does the right thing at that point in history, then bisect using the new test between that point and today.

If it doesn't do the right thing even then, write/backport a similar test for 1.0.23.38 and see if it ever worked right.

If it didn't, trace those functions mentioned above and compile small functions and stare at IR1 until you go blind or achieve illumination.