Programming Overview

This page provides a high-level overview of TIRx programming: the design philosophy behind it, the programming model, and the guides in this section.

Design Philosophy

Kernel DSLs are most effective when they choose the right boundary between the programmer and the machine. For mature kernels on mature hardware, that boundary can be high-level: the compiler hides thread assignment, memory movement, layout details, and instruction selection behind compact tensor or tile abstractions, and this works well for established kernel patterns.

At the frontier, the same boundary is under more pressure. New instructions, memory spaces, cooperation patterns, and kernel algorithms often appear before a compiler has enough built-in machinery to automate them well. At the same time, kernel programming is shifting toward agents, which work best with direct, predictable behavior: code that maps closely to what the hardware does, rather than to decisions a compiler makes behind the scenes.

TIRx chooses a lower and more explicit boundary. It is a generic language built for extension, and its core primitives stay direct and close to the native level of the hardware. The parts of a kernel that frequently require expert control, such as pipeline structure, synchronization, role assignment, memory placement, and backend intrinsics, are written directly in hardware-native source code.

On top of these primitives, TIRx provides a predictable convenience layer for the recurring tile-level structure through three constructs: execution scope, tensor layout, and tile operation dispatch. The layer is optional, and any part of a kernel can drop down to the native primitives.

The result is a language that can grow with the hardware. A new feature can first be used directly as a backend intrinsic, and later become a reusable tile operation once the pattern stabilizes. This is the core design philosophy behind TIRx: keep the foundation small and explicit, and let developers, agents, and the backend library extend it as new accelerator generations arrive.

The Programming Model

A TIRx program reads as a structured native kernel: loops, branches, tensors, synchronization, pipeline state, backend intrinsics, and hardware roles are written directly. Tile operations appear exactly where a repeated hardware-level operation should become reusable and dispatchable.

Authoring Layers and IR

TIRx programs use one TVMScript namespace alias:

from tvm_tirx.script import tirx as T

The namespace exposes three authoring layers. They share the same TIRx program, but enter the compiler at different levels:

Authoring layer	Syntax	Representation and lowering
Core language	T.*	Creates TIRx statements, expressions, tensors, and control flow.
Backend operations	T.cuda.* and T.ptx.*	Creates backend calls directly; these calls bypass tile operation dispatch.
Tile operations	T.cuda.tile.*	Creates a tile call that is replaced by a target-specific implementation during tile operation dispatch.

tvm_tirx.script.tirx is the construction syntax for the TIRx IR, not a separate IR. Tile operation dispatch and layout and scope lowering replace high-level TIRx nodes with lower-level TIRx statements and calls:

T.* ───────────────────────────▶ TIRx statements and expressions ──┐
T.cuda.* / T.ptx.* ────────────▶ backend calls ────────────────────┤
T.cuda.tile.* ─▶ tile call ─▶ tile operation dispatch ─────────────┤
                                                                   ▼
                                     layout and scope lowering ─▶ codegen

The model rests on three constructs:

• Execution scope describes which threads take part in an operation and at what level, such as a single thread, a warp, or a whole thread block. Ordinary control flow selects the hardware roles that enter a region.

• Tensor layout describes how a logical tensor maps to physical storage: which memory it lives in and how its elements are spread across threads and per-thread storage. Tile operation dispatch reads these declarations to choose an implementation.

• Tile operation dispatch selects an implementation for each tile operation according to the operation, the execution scope, the operand layouts, and the target, then generates the loops and addressing that apply it across the whole tile.

Across a full kernel, orchestration stays in ordinary source code, and the recurring hardware operations appear as tile operations.

Guides in This Section

• Language Basics covers defining and launching kernels.

• Control Flow covers conditions, loops, and early thread exit.

• Types, Tensors, and Memory covers element types, tensors, and memory spaces.

• Metaprogramming covers kernels parameterized by captured values, reusable code fragments, and compile-time specialization.

• Calling CUDA and PTX covers calling backend intrinsics, such as synchronization and warp shuffles, PTX instructions, and CUDA C++ device functions directly.

• Data Layout covers how tensor elements map to threads and memory.

• Tile Operations covers tile operations and the instruction guides.

• Compiling and Inspecting covers compiler options and inspecting generated code.

• Profiling with IKET covers profiling kernels with IKET.