Function best_candidate 

pub fn best_candidate(
    p: &SpatialProgram,
    target: &SpatialTarget,
) -> Option<Candidate>

The winning candidate (cost-minimal, deterministic tie-break).

★ ON A REGISTER-ACCUMULATOR TARGET THE RANKING IS ARITHMETIC INTENSITY, not the cycle model.

The model is a roofline fitted on TENSIX measurements — its own doc records a worst absolute error of 55% on that ledger — and it has never been fitted for a GPU. Asked to order GPU plans it preferred a 32-tile block over the 64-tile block that measured FASTER, which is the failure mode of using a model outside the data it was fitted on.

So for that target the choice is made on the physics we are sure of. A block computing osh · osw output tiles over ibw contraction tiles does osh · osw · ibw tile-multiplies per (osh + osw) · ibw tiles read, so intensity rises with the block and a GEMM at this size is bandwidth-bound — bigger is faster until a resource binds, and the candidate list only contains plans that already fit. Ties fall back to the model, so nothing about the Tensix path changes.