commit d5e7e1a3f6222191af65cfae4c7b015631d8ce73
parent 909fef3f7c05ca621e9975078973d15023839ff8
Author: Ryan Sepassi <rsepassi@gmail.com>
Date: Sat, 18 Jul 2026 09:08:07 -0700
docs: plan DataLayout-backed CG addressing
Diffstat:
1 file changed, 14 insertions(+), 0 deletions(-)
diff --git a/doc/plan/TODO.md b/doc/plan/TODO.md
@@ -103,6 +103,20 @@ Terse backlog rescued from plan docs that were deleted once their shipped design
moved up to the design set. Fuller context for each is in git history (the named
doc at `HEAD~`).
+### DataLayout-backed CG IR
+
+- **Add a `DataLayout` abstraction and delay aggregate address lowering in the
+ existing CG IR.** The IR should remain associated with a selected target data
+ layout, as LLVM IR is, rather than become fully target-agnostic or gain another
+ IR layer. Today `kit_cg_field` becomes a byte displacement and `kit_cg_elem`
+ becomes a concrete byte stride before the recorder/backend sees them. Preserve
+ record + field identity and element type/scale as GEP-like symbolic IR
+ operations, then have each backend query the module's `DataLayout` for concrete
+ offsets and strides. Make `DataLayout` the single authority for pointer/scalar
+ sizes, alignment, record and bit-field layout, and endianness. This deliberately
+ delays layout commitment without promising that an already-produced module can
+ be safely retargeted to an incompatible ABI.
+
### Arch-backend parity — x64/rv64 vs the aa64 reference (was `ARCH.md`)
- **x64/rv64 tail-call realization.** `x64_no_tail` / `rv_no_tail` still bail on