[ Home ]
SBCL Internals

The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed
[ Home ] [ Recent Changes ] [ About CLiki ] [ Text Formatting ]
As of 0.8.14.11 SBCL compiler supports stack allocation of actual arguments in local calls, corresponding to formal arguments, declared DYNAMIC-EXTENT.

IR1

During local-call conversion, if the function has DYNAMIC-EXTENT arguments, we put a cleanup? of kind :DYNAMIC-EXTENT around the combination and mark LVAR?s, corresponding to dynamic extent arguments. The cleanup? contains a list of the corresponding LVAR?s, and every LVAR? contain a reference to the cleanup?.

Physical environment analysis

We iterate over cleanup?s of kind :DYNAMIC-EXTENT and decide which LVAR?s will actually carry stack-allocated objects. The condition is the following: there should be only one use being known COMBINATION and the STACK-ALLOCATE-RESULT-optimizer for the function should return true.

TODO: implement it when all uses can stack allocate results; it is also possible for some uses allocate on stack, while for others - on heap or to not allocate at all.

Stack analysis

Stack-allocated LVAR?s are pushed at their constructor calls; they are not popped, but we mark them as live in every block?, protected by their cleanup?s. They are unmovable (because in general it is impossible to trace all references to them); it is implemented by copying all LVAR?s, alive after allocator node (which thus should be the last node? of its block?), to the live set at the end of every block inside the cleanup?.

IR2

There are two approaches to implement deleting unused stack-allocated objects. When control stack grows downwards, we use an additional TN, keeping stack pointer before the object allocation. When control stack grows upwards, the pointer to the beginning of the object is the same (modulo lowtag) as the stack pointer before allocation, so we do not need a TN, but we need additional VOPs %%POP-DX and %%NIP-DX.

[In fact, it was never implemented in the latter way: lowtag requires 3 bits on 32-bit platforms, and stack pointer is usually only 2^2-bytes aligned. So before stack allocation of objects the address should be additionally corrected. Thus the original address should still be saved.]

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively