TensorPlay compiler roadmap: from graph capture to native execution

What is in the compiler stack today?

The repository combines Python graph capture, Graph/Pass IR, the Stax native executor, and Triton/TVM backends. It does not try to reproduce a complete industrial compiler in one step; it makes the input, output, and failure boundary of each layer explicit first.

The alignment plan is organized as L1 through L7: capture frontend, IR and passes, symbolic shapes, AOT autograd, code generation, guard management, and export IR. PassManager, constant folding, dead-code elimination, ShapeProp, metadata specialization, shape guards, and parts of the AOT native path are present; the later layers remain roadmap items.

Graph capture: what can be specialized?

Capture can read metadata such as shape, dtype, device, ndim, and len, then specialize safe Python control flow into the graph. Tensor data remains symbolic. If a branch depends on actual data, fullgraph mode should report GraphCaptureError instead of producing a graph that is accidentally correct only for the current input.

Dynamic capture also needs guards. If a graph reads x.shape[0] to choose a branch, the cache key must record that touched dimension. Reusing one specialized graph for a different size would turn a performance optimization into a silent correctness bug.

if x.shape[0] > 2:
    y = x.relu()
else:
    y = x.sigmoid()

shape read -> guard -> specialized graph
data-dependent branch -> explicit capture error

Stax performance work: expose the cost first

The roadmap lists codegen cache, autotune, cudagraphs, decomposition tables, and broader fusion as later milestones. They affect repeated compile cost, kernel configuration, launch overhead, operator semantics, and cross-operator optimization. Until those capabilities are complete and benchmarked, it would be inaccurate to claim that every compiled model is faster.

Acceptance should return to benchmark/benchmark_resnet_classification.py: keep weights, data order, input, and timing rules fixed, then record first-compile cost, steady-state throughput, p50/p95 latency, logits parity, and codegen. Each optimization should say which cost it improves.

• Compile cost: wrapper and first-pass time.
• Runtime cost: steady-state p50/p95, throughput, and memory behavior.
• Correctness cost: logits and prediction parity between eager and compiled paths.
• Execution evidence: actual native, Triton, TVM, or fallback codegen.

What can we say accurately today?

• We can say that capture, passes, lowering, and kernel execution are separated into inspectable boundaries.
• We can say unsupported graph structures fail explicitly or follow a documented fallback contract with numerical checks.
• We can say performance is being measured configuration by configuration through GEMM, ResNet, and compiler comparisons.
• We cannot say that every model, GPU, dtype, or training workload is faster than a mature framework.