XTC, A Research Platform for Optimizing AI Workload Operators

TL;DR

XTC tackles the problem of comparing and prototyping AI workload optimizations across compiler ecosystems by decoupling scheduling from code generation and providing a unified API and cross-backend measurement harness. The platform supports multiple backends (TVM TE and MLIR Transform), a suite of scheduling primitives, and an extensible research workflow for implementing new scheduling languages and exploration strategies. Empirical evaluations show XTC can rival hand-tuned C implementations at the operator level, reveal backend-specific limitations, and enable end-to-end graph optimization within existing ML pipelines. By offering reproducible evaluation, design-space exploration, and modular backend integration, XTC accelerates research in compiler-driven AI optimization.

Abstract

Achieving high efficiency on AI operators demands precise control over computation and data movement. However, existing scheduling languages are locked into specific compiler ecosystems, preventing fair comparison, reuse, and evaluation across frameworks. No unified interface currently decouples scheduling specification from code generation and measurement. We introduce XTC, a platform that unifies scheduling and performance evaluation across compilers. With its common API and reproducible measurement framework, XTC enables portable experimentation and accelerates research on optimization strategies.

Figures (14)

• Figure 1: XTC's high-level components and their interactions. XTC allows to decouple research on scheduling strategies from code generation, validation and measurement.
• Figure 2: A non-optimized matrix multiplication in C.
• Figure 3: The target implementation of the matrix multiplication in Figure \ref{['fig:naive_matmul']}. CPU-dependent instructions (i.e. intrinsics) are hidden behind C macros.
• Figure 4: The scheduling of a matrix multiplication using the XTC API (MLIR backend).
• Figure 5: An example of an MLIR Transform dialect script applied to a matrix multiplication equivalent to the one in Figure \ref{['fig:naive_matmul']}. The transformation state is carried by MLIR variables. In blue, the evolving state of the linalg.matmul operator being optimized. In green, the evolving state of the low-level loops (scf.for) materialized during the tiling. In red, the evolving state of the function containing the operator (func.func @myfun).