Skip to main content

from_pipe

Function from_pipe 

Source
pub fn from_pipe(
    sends: &[i64],
    target: &SpatialTarget,
) -> Result<SpatialProgram, SpatialReject>
Expand description

★ A RECOGNIZED PRODUCER/CONSUMER PIPE, AS SPATIAL IR — the template that retires codegen_tt::concurrency_mesh’s hand-written two-core program.

The shape was already in the IR’s vocabulary. A task sending N values into a pipe while main receives and folds them is a LOAD on one engine feeding a FIFO edge, and a REDUCTION on the other draining it — which is precisely what the retired emitter spelled out by hand as two baby-RISC-V kernels around a circular buffer. Nothing new was needed: ChoreoOp::{Reserve,Push,Wait,Pop} are the circular-buffer discipline, and a fold is not an operator but an IterKind::Reduce axis.

The sends are constants OF THE RECOGNIZED PROGRAM, so they ride as the input tensor’s Values init rather than as a const uint32_t vals[N] baked into a kernel string. That is the whole difference between a template and a lowering: the same numbers, but reachable by every pass, every census and the evaluator instead of being sealed inside C++ text.

Numerics — why fp32 and not an integer datapath. A pipe of integers has an integer sum, so the fold must be exact. Asking for Precision::Int64 would make trivial_plan choose AccPolicy::I64, which the Tensix printer refuses: the matrix engine is float-primary, the same hardware fact that retired the int8 GEMM path (measured 0/4096 correct on Wormhole AND Blackhole). Fp32 represents integers exactly below 2^23, so a bounded pipe keeps NumericsClaim::Exact on the validated datapath. A pipe whose fold could leave that range is REFUSED rather than silently rounded — the claim has to be true, not convenient.