Phase 2: Element-wise matrix operations (matrix_add, matrix_add_transposed)

[Ravenwater]

Goal

Add 2D element-wise operators (matrix_add, matrix_add_transposed) to V4. Phase 2 of the operator-expansion plan (docs/v5/operator-validation-expansion-plan.md).

Why second

Trivially extends Phase 1's element-wise infrastructure. Same AI as vector_add but rectangular access exposes layout & coalescing differences. Critical for transformers: residual connections (x + sublayer(x)) are matrix_add hot paths.

Scope

• matrix_add: row-major contiguous, both operands aligned
• matrix_add_transposed: B operand accessed column-strided (validates the analyzer's stride-penalty model)

Footprint

matrix_add (M, N): flops = M*N, bytes = 3*M*N*bpe → AI = 1/(3*bpe)
matrix_add_transposed (M, N): same FLOPS, B accessed with stride

Reuse model

Same as vector_add (zero reuse). The interesting bit is the access pattern, not the reuse.

Decision needed

Model transposed-B as a separate op, or just expect the analyzer's prediction to match measured (and watch the latency-band fail when transposition matters)?

Recommendation: separate op. The whole point is to validate the "transposed memory penalty" model explicitly, and naming it makes the ablation a first-class operator.

Deliverables (1 PR)

• footprint + reuse model + sweep generator + measurer + i7 / Orin Nano baselines + visualizer

Estimated scope

~1-2 days.

Acceptance criteria

• Both operators predict latency within 20% of measured for shapes >1ms
• Transposed variant correctly predicts the access-pattern penalty (predicted slower than untransposed for stride-unfriendly shapes)
• V4 floor tests pass

Cross-link

• Plan: docs/v5/operator-validation-expansion-plan.md (Phase 2)