Compile-time stack flattening (promote stack slots to SSA/registers)

[tetsuo-cpp]

Summary

Promote the abstract Forth data stack from a runtime memref<256xi64> buffer into SSA values (and ultimately GPU registers) wherever stack depth and slot identities are statically known.

Motivation

Today, convert-forth-to-memref materializes !forth.stack as a fixed memref<256xi64> plus an index stack pointer. Almost every stack word becomes load/store + SP arithmetic. That is a large tax on every kernel, including ones that would otherwise be competitive after warp ops (#10), atomics (#43), MMA (#11), or unrolling (#12).

Local variables already show the preferred model: they are bound with forth.pop / forth.push_value and map cleanly to SSA/registers. The default data stack should aspire to the same lowering when depth is static.

Without stack flattening, new GPU primitives will still sit on a memory-backed stack machine and leave large performance on the table.

Current behavior

• !forth.stack → memref<256xi64> + SP (kStackSize = 256 in ForthToMemRef.cpp)
• DUP/SWAP/+/etc. lower to explicit loads, stores, and pointer updates
• Residual stack traffic survives into NVVM/PTX as local memory pressure

Proposed design

Add a stack simulation / flattening pass (either before or instead of naive full-buffer materialization):

1. Simulate stack depth and slot provenance through straight-line code and simple control flow.
2. Rewrite stack ops into SSA values for known slots (same spirit as locals).
3. Keep a residual runtime stack only when depth or identity is not statically known (e.g. data-dependent depth, complex irreducible control flow).
4. Verify that residual and promoted paths agree on stack effect at merge points (phi/block args).

Placement options

Option	Notes
A. Before MemRef	High-level forth IR → SSA-heavy forth (or arith/cf) with residual stack ops
B. During MemRef	Emit SSA + optional alloca residual instead of always allocating 256 cells
C. After MemRef	Mem2reg-like promotion of the stack buffer (harder; aliasing/SP updates)

Prefer A or B so control-flow and word boundaries see a cleaner model early.

Acceptance criteria

• Straight-line kernels with fixed stack depth compile with little or no stack alloca traffic in the post-MemRef IR
• Control flow (IF/ELSE/THEN, loops) either fully promotes or clearly falls back to residual stack with correct merges
• User words still compose correctly (stack in/out as SSA tuple or residual)
• LIT tests for promotion success cases and residual fallback cases
• At least one GPU microbenchmark (e.g. matmul inner loop) shows reduced local memory / better SASS than the current lowering (document methodology)

Non-goals

• Full Forth exception/catch stack
• Dynamic stack depth as a first-class language feature
• Replacing the programmer-facing stack model (source language stays stack-based)

Related

• Locals implementation (register-friendly path already exists)
• Downstream of this: richer opt pipeline (inlining/CSE/LICM), warp/MMA features (Warp-level primitives: shuffle and reductions #10, Tensor core / MMA intrinsics #11)