Skip to main content

Module forward

Module forward 

Source
Expand description

forward — one section’s result handed to the next section’s compute, never through memory.

★ A RESULT ONLY ITS NEXT READER NEEDS NEVER LEAVES THE SITE. Section k computes a tensor and stores it; section k+1 loads the same tiles back and computes on them. When nothing but section k+1 reads the tensor — no later section, no Show, no carried state — the round trip moves nothing anyone keeps: the store, the load, the boundary between the two sections and the second section’s own acquire are all overhead on a chain of dependent sections. Forwarding joins the two TEMPLATES into one section: the buffer the producer’s store read now feeds the consumer’s compute, and the tensor is gone. It joins templates (Phase::Template), before tile, so the joined section is tiled, placed, scheduled and certified as one and fuse_generic then folds a map into the map it follows; and it joins two sections tile has planned (Phase::Tiled), where a matmul’s items — a work item per output tile in its template — meet the one item a row map walks only once the plan has grouped them.

★ THE STORE AND THE LOAD AGREE, OR NOTHING IS JOINED. The producer stores the tensor once, from a buffer nothing else reads; the consumer loads it once, into a buffer only computes read; the two sections walk the same work items on the same tile, and for every one of them the store and the load address the same tiles of the same tensor in the same order (AccessPattern::tiles_at). Then the page the producer packs is exactly the page the consumer would have loaded. A store whose address steps with its item or its sub-block — a matmul’s — agrees only under the plan the template’s items were laid out for: one item, packed once. Two templates join through one only where each walks one item, a tile, which tile can only plan as one item packed once: a wider pair, whose plan packs a block of tiles an item where the consumer was laid out a tile an item, would compute its first tile alone. Two planned sections join through one only under a plan of one item whose every matmul packs once (one_block). Whether the tensor is dead after the consumer is the caller’s to know (it reads the whole program); this pass never decides it. Nor is whether the join keeps what the value was proven to hold: the buffer that now carries it (Joint::carrier) holds what the producer’s compute proves, and the caller, holding the front end’s intervals, judges whether that is wider than what a load of the tensor would have read.

Structs§

Joint
Two sections joined into one.

Functions§

forward
first and second joined through tensor, the one first stores and second loads, or None where the store and the load do not agree (see the module doc).
one_block
Whether p, a section the passes have planned, holds a join through a store that steps with its item or sub-block: one work item, and every matmul a single sub-block.