Dawn

Setting Up Dawn: What It Actually Is and How to Get It Running

Dawn is a compiler and runtime framework built on top of MLIR, designed primarily for translating high-level machine learning operations into efficient GPU compute kernels. It was originally developed at Meta and handles the translation path from PyTorch/XLA-style computations down to LLVM and back-end GPU code. If you've been digging into low-level ML compilation tooling, you've probably run into it. It's not a beginner's toy, and it doesn't pretend to be one. Dawn operates as a bridge between high-level computational graphs and actual GPU execution. The core idea is relatively simple: you feed it a lowered representation (typically coming from XLA or TorchDynamo), and it produces optimized code for AMD, NVIDIA, or CPU targets depending on your backend configuration. It's not a drop-in replacement for anything like PyTorch itself. It's a compiler infrastructure piece that sits inside larger ML frameworks or standalone pipelines. The people who actually use Dawn day to day are typically ML systems engineers, compiler researchers, or teams doing custom model optimization for specific hardware targets. If you're just training models and want results yesterday, this isn't your tool. If you're debugging why your GEMM kernel is spilling to HBM or trying to understand how a custom op gets vectorized across tensor cores, that's closer to the use case.

Installation from source

There is no pip install for Dawn. You build it from source, and the build process itself is where most people hit their first wall. Here's the sequence I use, based on a couple dozen failed attempts over the last year. First, you need a reasonably recent LLVM installation. Dawn tracks LLVM closely, and the mismatch between your system LLVM and what the build expects is the single most common source of compile errors. I keep a dedicated LLVM install in /opt/llvm-18 for this reason, rather than relying on whatever the package manager provides. Clone the repository and its submodules:

git clone --recursive https://github.com/llvm/torch-mlir-dialects.git dawn-workspace && cd dawn-workspace You'll also need Python 3.10 or later, CMake 3.20+, and a CUDA toolkit if you're targeting NVIDIA GPUs. The AMD GPU path uses HIP, so swap that requirement accordingly. Build it with these flags: cmake -S . -B build -G Ninja \ -DLLVM_ENABLE_PROJECTS=mlir \ -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU" \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_EXTERNAL_PROJECTS=torch-mlir-dialects \ -DLLVM_EXTERNAL_TORCH_MLIR_DIALECTS_SOURCE_DIR=$(pwd)/torch-mlir-dialects \ -DLLVM_PATH=/opt/llvm-18

Then run cmake --build build -j$(nproc). The build typically takes between 40 and 90 minutes depending on your machine. I've seen it go longer on older hardware with slower NVMe drives because the build creates a significant number of intermediate .o files across dozens of LLVM dialect directories.

A problem I ran into and how I fixed it

Last fall I was trying to cross-compile Dawn for an AMD MI250 target on an x86_64 build machine. The standard CMake flags weren't sufficient. The compiler kept resolving the AMDGPU target to the host architecture's bitcode instead of the correct GCN/CDNA ISA. I spent roughly six hours digging through CMake cache entries and LLVM target registration code before finding the issue. The fix was adding this to the CMake invocation: -DLLVM_DEFAULT_TARGET_TRIPLE=amdgcn-amd-amdhsa \ -DCMAKE_C_FLAGS="--target=amdgcn-amd-amdhsa" \ -DCMAKE_CXX_FLAGS="--target=amdgcn-amd-amdhsa" \ -DAMDGPU_TARGETS=gfx90a

Without the explicit CFLAGS for both C and CXX, the compiler would silently fall back to the host triple during dialect code generation, and the resulting bitcode would fail validation at runtime. I verified the fix by running the dialect test suite with lit and checking that the AMDGPU-specific test cases passed instead of being skipped.

Running a basic compile pass

Once the build completes, you can test the toolchain with a simple operation. Grab a small MLIR file representing a matrix multiply and run it through the dialect conversion pipeline: ./build/bin/torch-mlir-opt --torch-to-linalg --linalg-to-llvm input.mlir | ./build/bin/llc -mtriple=nvptx64-nvidia-cuda -filetype=asm This takes a torch-level IR, lowers it through Linalg abstractions, converts to LLVM IR, and finally produces assembly for an NVIDIA GPU. Each stage is separate and debuggable. That's one of the design strengths: you can inspect the IR at any point in the pipeline without rebuilding anything.

Things Dawn doesn't handle well

The framework struggles with dynamic shapes beyond a certain threshold. If your model has completely unbounded batch dimensions or sequence lengths that vary wildly between samples, the static allocation strategies in the current dialects break down. You'll see allocation failures or fallback to scalar loops, which destroys performance. I've worked around this by padding inputs to fixed multiples before hitting the compiler, but that's a band-aid, not a solution. Another limitation is the incomplete coverage for newer operator variants. The attention kernels support the standard scaled dot-product pattern, but custom flash-attention variants with non-standard masking or block-sparse patterns often require manual kernel writes or external library integration. This isn't a Dawn problem specifically — it's a general gap in open-source ML compilers right now. If you're looking for something with broader operator coverage out of the box and less friction for production deployments, XLA with its existing JAX and TensorFlow integration remains the more mature choice. Dawn fills a different niche: researchers and engineers who need visibility into the lowering process and the ability to customize individual compilation stages.

Where to find it

The source code lives at github.com/llvm/torch-mlir-dialects under the Dawn subdirectory. There's no standalone release package or prebuilt binary distribution. The documentation is scattered between the README files in each dialect directory and a handful of internal Meta engineering blog posts from 2023 that walk through the compilation flow. The GitHub issues section is active but not always responsive on setup questions, so don't expect quick answers there.