CUDA Tile IR is an MLIR dialect for writing tiled GPU kernels

What the project is trying to express

CUDA Tile IR is an MLIR based intermediate representation and compiler infrastructure for CUDA kernel optimization, focusing on tile based computation patterns and optimizations targeting NVIDIA tensor core units. The project describes itself as a comprehensive ecosystem for expressing and optimizing tiled computations for NVIDIA GPUs, simplifying the development of high-performance CUDA kernels through abstractions for common tiling patterns, memory hierarchy management, and GPU specific optimizations.

Three phrases in that description carry the weight. Tile based computation is the programming model, where a kernel works on tiles of data rather than element by element, which is what the tensor core units actually consume. Memory hierarchy management is the other half of it, because a tiled kernel is mostly about moving tiles between global memory, shared memory and registers in the right order. And MLIR is the substrate, which means this is not a new language but a dialect, an extension of an existing intermediate representation with its own operations and types.

That last point is the one to be clear about for an adopter. The project is a library, not a tool you run. You do not hand it a .cu file and get a faster kernel. What you get is a set of abstractions that a compiler or a kernel library can be built on top of, and the documentation in the repository is written for someone integrating that library into a build.

The audience is therefore GPU kernel developers and compiler engineers, at a company or a research group that writes its own kernel infrastructure. The open source release is aligned with the CUDA Toolkit 13.1 release, and the project points to the CUDA Tile documentation on the NVIDIA developer site and to the CUDA Tile IR specification, which is where the formal semantics, the operations and the type system are defined.

Four components: a dialect, bindings, bytecode and a conformance suite

The core components section lists what the project is made of, and the list is short enough to be a useful map.

The CUDA Tile Dialect is a domain-specific MLIR dialect that provides first-class operations and types for tile based computations. First class is the operative word: rather than encoding a tile as a sequence of raw operations, the dialect gives it an operation and a type, so the passes downstream can pattern match on it.

The Python bindings provide a complete Python API for programmatic IR construction, manipulation, and transformation. This is the piece that makes the project usable by a team that does not want to write C++ to build a program, and it is disabled by default in the build, which is worth noting because it means the default configuration is the narrow one.

The bytecode is an efficient binary representation with support for serialization and deserialization between the CUDA Tile dialect and a binary format. A binary format for an IR is what you need when the producer of the IR and the consumer of the IR are different programs, or different runs, or different machines.

The conformance test suite consists of comprehensive tests ensuring compliance with the CUDA Tile specification and validation of dialect semantics. That is a stronger statement than a test suite, because it says the tests are written against the specification rather than against the implementation, which is the property that makes a specification meaningful.

Together these four cover the lifecycle of an IR: construct it, in C++ or in Python, serialize it, and verify that what you built matches what the specification says it should mean.

The LLVM commit pin is the real build constraint

The build requirements read like a typical CMake project until you reach the LLVM line, and then they become the whole story.

The prerequisites are CMake 3.20.0 or higher, a C++17 compatible compiler, Python 3.6 or later for the Python bindings, and MLIR/LLVM sources or pre-built libraries at a compatible commit, with the exact version pointed at in cmake/IncludeLLVM.cmake at line 29. The Ninja build system is optional.

So the constraint is not a version range, it is a commit hash. The project needs MLIR and LLVM at that specific commit, and the documentation repeats the point in each of the three build modes: the commit hash of the source must be compatible with the commit specified in the include file. This is not an unusual requirement for a project built on LLVM, but it is the requirement that decides whether your build works.

The three ways of satisfying it are the useful part of the documentation. The first is automatic download from GitHub, which is the default: CMake downloads the MLIR and LLVM sources from the official repository and builds them at the compatible commit. The documentation is honest that this is the slowest option but that it requires no manual LLVM setup. The second is to use local LLVM sources, with the flag -DCUDA_TILE_USE_LLVM_SOURCE_DIR pointing at them, and the same commit compatibility requirement. The third is to link against pre-compiled LLVM libraries, with -DCUDA_TILE_USE_LLVM_INSTALL_DIR.

The choice is between convenience and time. The automatic path costs a full LLVM build on every clean configure, which is a large number of cores for a large number of minutes. The pre-built path is fast but only works if you have a matching LLVM install, and the matching includes whether it was built with the Python bindings enabled, which is the trap described in the next section.

Configuring, building and testing

The quick start is a configure, a build and a test run, and the flags are the interesting part.

# Configure
cmake -G Ninja -S . -B build \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLVM_ENABLE_ASSERTIONS=OFF \
  -DCUDA_TILE_ENABLE_BINDINGS_PYTHON=ON \
  -DCUDA_TILE_ENABLE_TESTING=ON

# Build
cmake --build build

# Run tests
cmake --build build --target check-cuda-tile

The MLIR and LLVM sources are downloaded automatically from the llvm-project repository on GitHub, so a first build is a long build. Assertions are turned off, which is the usual choice for a release configuration, and the two CUDA Tile specific flags enable the Python bindings and the test suite.

The Python bindings flag is worth a second look, because of an asymmetry in the documentation. The bindings are disabled by default, and when you build MLIR and LLVM from sources the MLIR Python bindings are enabled automatically. But when you use pre-built LLVM libraries, you must ensure they were built with -DMLIR_ENABLE_BINDINGS_PYTHON=ON. So the fast path and the convenient path are not the same path, and the failure mode is a Python module that is missing rather than an error at configure time.

There is also a ccache option, -DCUDA_TILE_ENABLE_CCACHE=ON, and when LLVM is being built from sources this setting is automatically propagated to the LLVM build, which is a small courtesy that saves a lot of time on a machine that rebuilds LLVM often.

Testing uses LLVM's lit testing infrastructure, and it is disabled by default, enabled with the testing flag, and run with the check-cuda-tile target. Using the same infrastructure as LLVM means the test format, the file layout and the reporting are the ones an LLVM developer already expects, which matters for a project that expects to be developed alongside LLVM.

Linking it in, or vendoring the sources

The integration section gives two options, and the choice is between linking against an installation and building the sources as part of your project.

The first option is to use pre-built CUDA Tile libraries, which means including the headers from the install directory and linking the specific libraries you need. The example shows the granularity:

include_directories(${CUDA_TILE_INSTALL_DIR}/include)

# CUDA Tile dialect
target_link_libraries(your_target PRIVATE
  CudaTileDialect           # CUDA Tile dialect operations and types
)

# Bytecode support.
target_link_libraries(your_target PRIVATE
  CudaTileBytecodeReader    # Read bytecode format
  CudaTileBytecodeWriter    # Write bytecode format
)

So the dialect and the two bytecode libraries are separate link targets, and a consumer that only needs the dialect does not pull in the bytecode reader and writer.

The second option is to build the sources as part of your project, and the documented way is CMake's FetchContent, with the repository URL and a tag:

include(FetchContent)

set(CUDA_TILE_SOURCE_DIR ${CMAKE_BINARY_DIR}/_deps/cuda_tile-src)
set(CUDA_TILE_BINARY_DIR ${CMAKE_BINARY_DIR}/_deps/cuda_tile-build)

FetchContent_Declare(
  cuda_tile
  GIT_REPOSITORY https://github.com/NVIDIA/cuda-tile.git
  GIT_TAG        main
  SOURCE_DIR     ${CUDA_TILE_SOURCE_DIR}
  BINARY_DIR     ${CUDA_TILE_BINARY_DIR}
)

The options are then set before making the content available, with the LLVM install directory, the Python bindings on and the testing off, and FetchContent_MakeAvailable is called. The headers are then included from both the source and the binary directory, and the libraries are linked as in the first option.

The tag in that example is main, and that is a detail worth pausing on. Tracking a moving branch in a FetchContent declaration means your build changes when the upstream repository changes, and for a project that pins an LLVM commit, that is a compatibility question the example leaves to you. A tag or a commit hash of your own would be the safer choice in a production build, and the example is showing the shape of the integration rather than the recommended pinning.

Versioning, licence and what the release names tell you

The version numbers are tied to the CUDA Toolkit rather than to the project alone, and the release names are unusually informative because they include the reason for the release.

The recent tags are v13.3.4 on 2026-08-27, v13.4.0 on 2026-09-10 and v13.4.1 on 2026-09-28. The first and third are labelled as a fix for a breaking LLVM commit, with the commit hash in the name, and the middle one is the plain release. That naming tells you the project tracks LLVM closely enough that an upstream breaking commit requires a release of its own, which is the same fact as the commit pin, seen from the release history side.

The open source release is aligned with the CUDA Toolkit 13.1 release, and the specification is published separately, with the documentation pointing at the CUDA Tile IR specification pages for version 13.1. So there are three version numbers in play, the library version, the CUDA Toolkit version and the LLVM commit, and the project is explicit about how they relate.

The licence field on the repository is listed as a custom licence that GitHub cannot classify, and the repository contains a LICENSE.txt file, so the licence text is the authoritative source and the metadata badge is not. For a project that is part of a compiler toolchain, that is the file to read before you incorporate it into anything you distribute.

The repository layout is small and conventional for a CMake project: include/, lib/, python/, test/, tools/, scripts/ and cmake/, with a CMakeLists.txt at the root, a .clang-format for the C++ sources and the licence file. The last push was on 2026-09-28 and the repository is not archived, so the project is being worked on and the release line is moving at the pace of the LLVM commits it tracks.

Editorial conclusion

CUDA Tile IR suits a kernel developer who is comfortable with MLIR and wants first class operations and types for tiled computation, and a team that wants to build tile based patterns targeting tensor cores rather than expressing them by hand. It is the wrong choice if you want a drop-in compiler you can point at a kernel file, because the deliverable is a library and a dialect that you integrate into a build, and a poor match if you cannot accept an exact LLVM commit pin, because the MLIR and LLVM sources must match a specific hash. Before building, read the pinned commit in cmake/IncludeLLVM.cmake and decide which of the three LLVM integration modes you will use, since the automatic download is the slowest of the three.

Frequently asked questions

Official sources

1. Issues
2. NVIDIA/cuda-tile on GitHub
3. README
4. Releases