Yorick Peterse (Dec 23 2023 at 22:34): Yorick Peterse (Dec 23 2023 at 22:34):Does Cranelift make any attempt to reuse existing stack slots/stack space? i.e. if I allocate slot A, use it for a while, then stop using it and allocate slot B, does Cranelift do anything clever to reduce stack memory usage?
Chris Fallin (Dec 23 2023 at 22:59):If you mean the explicit stackslots in the preamble (ss0 = stack_slot ... then stack_load / stack_store / stack_addr), no, those are not coalesced. In theory we could analyze the live ranges and look for escaping of the address, and do an LLVM-like mem2reg pass that lifts non-escaped non-aliasing memory slots to SSA, but in general we try to avoid that kind of complexity and correctness risk; less "magic" with brittle cliffs, more simple canonicalization on code with explicit intentions.
On the other hand, register allocator-managed spillslots are coalesced, because we know their exact live ranges (because the regalloc manages the moves into and out of slots). If a producer wants to benefit from that coalescing, it could lift a stackslot-stored value or struct to SSA itself (like SROA), which then makes the ranges explicit
Yorick Peterse (Dec 23 2023 at 23:10):Ah gotcha. The context here is I'm trying to see what would be needed to pass data around that's on the stack, e.g. a struct returned by a function or passed to one as an argument. Based on the above it seems I'd have to devise some sort of mechanism to reuse slots no longer in use :smile:
Chris Fallin (Dec 24 2023 at 01:04):Makes sense -- yep, it seems like a scheme that manages and reuses slots at a layer above Cranelift would make sense. FWIW, @bjorn3 probably has thoughts/suggestions here too, from implementing rustc's ABI (presumably including struct returns?) lowered to CLIF
bjorn3 (Dec 24 2023 at 08:01):cg_clif reuses the abi calculation code of rustc. Using that outside rustc is non-trivial.
Last updated: Dec 23 2024 at 13:07 UTC