fix: emit lifetime markers for lowered call temporaries

[ghaith]

Problem

Calling a function that returns an aggregate (string, struct) allocates a caller-side temporary to hold the result. Each call site gets its own temporary sized to the declared return type — STRING[2048] for every stdlib string function (CONCAT, *_TO_STRING, …) — with no lifetime information attached, so LLVM keeps every slot alive for the whole function. A body with ~50 string operations already needs >100 KB of frame and overflows small task stacks at function entry.

Fix

Emit llvm.lifetime.start/end around each lowered statement's call temporaries, so LLVM's stack coloring can overlap slots whose lifetimes don't intersect. The frame then grows with the deepest single statement instead of the number of call sites: a string-heavy test body drops from ~111 KB to ~10 KB of frame at the default optimization level.

Temporaries whose address escapes their statement must not be marked dead at statement end — stack coloring could hand their slot to a later statement while a pointer still refers to it. These are pinned (Allocation::statement_scoped = false, no markers): ADR/REF arguments, REF= right-hand sides, and interface fat-pointer captures (already wrapped in ADR by the polymorphism lowering). Loop bookkeeping temporaries keep their function-long storage since their values cross iterations.

Scope

This only benefits builds where the LLVM backend optimizes: stack coloring is a machine pass that does not run at -Onone, so unoptimized builds keep their current frame sizes. Planned follow-ups (separate PRs):

• optimisation-level controls so that builds which want a debug-friendly experience can still run selected backend optimisations such as stack coloring
• result buffers are still fully zero-initialized at every call site; marking aggregate out-parameters writeonly would let LLVM eliminate those memsets

Testing

• codegen snapshot tests for marker placement, including nested calls (start/start … end/end) in string_tests
• lowering unit test asserting temps whose address escapes via ADR are pinned and later statements get their own slot
• lit end-to-end suite, including a new test asserting an unassigned aggregate return reads as an empty string

🤖 Generated with Claude Code

[github-actions]

Build Artifacts

🐧 Linux

Artifact	Link	Size
deb-x86_64	Download	38.4 MB
schema	Download	0.0 MB
stdlib	Download	32.3 MB
plc-x86_64	Download	43.4 MB
deb-aarch64	Download	30.8 MB
plc-aarch64	Download	43.3 MB

From workflow run

🪟 Windows

Artifact	Link	Size
stdlib.lib	Download	4.0 MB
stdlib.dll	Download	0.1 MB
plc.exe	Download	38.2 MB

From workflow run

[riederm]

ui .... bit unusual to see such an optimization in the frontend, but the complexity is surprisingly low. On the other hand, aren't both strategies (lifetimes and tmp-slots) try to solve the exact same problem? do the lifetimes still have any effect if you optimize already in the compiler-frontend?

[riederm]

ui .... bit unusual to see such an optimization in the frontend, but the complexity is surprisingly low. On the other hand, aren't both strategies (lifetimes and tmp-slots) try to solve the exact same problem? do the lifetimes still have any effect if you optimize already in the compiler-frontend?

... I just re-read my comment and I have to add - the complexity is lower than I expected, but it is still very unusual complexity in the compiler frontend 😆

[ghaith]

ui .... bit unusual to see such an optimization in the frontend, but the complexity is surprisingly low. On the other hand, aren't both strategies (lifetimes and tmp-slots) try to solve the exact same problem? do the lifetimes still have any effect if you optimize already in the compiler-frontend?

So i wanted to only do the lifetimes, but the problem is that the builder we are shipping in the IDE builds with -Onone and hence the lifetime does not take effect