The umbrella covers the DSL, the `tile` dialect, and the "two backends, one source" story. CPU and GPU are sibling lowerings of that dialect: same frontend, very different optimization and tooling concerns. On CPU the question is "vectorize and fuse" (turn nested tiled loops into FMA-rich vector code that LLVM can schedule against AVX2). On GPU the question shifts to memory hierarchy and tensor cores.

Stage 1: `tile` → `linalg` + `memref` + `scf`. A pattern-rewrite pass turns `tile.matmul` into `linalg.fill 0` + `linalg.matmul`, `tile.load` into `memref.subview` (plus a `memref.copy` when crossing memory spaces), `tile.store` into `memref.copy`, and `tile.tile_grid` into nested `scf.for` (or `scf.forall` under the parallel directive). `!tile.tile<...>` becomes `memref<shape x elem, memspace>`.

Stage 2: standard MLIR passes lower to LLVM dialect (linalg bufferized and lowered to loops, scf to structured control flow, memref to pointers and offsets, arith/func to their LLVM-dialect equivalents).

Stage 3: `mlir-translate -mlir-to-llvmir` produces LLVM IR; `llc -mtriple=x86_64 -mattr=+avx2` produces x86 assembly. The named pipeline (`--tile-cpu-pipeline`) can run end-to-end or stop at any intermediate stage for inspection.

Vertical fusion: `tile.elementwise` whose first operand is a `tile.matmul` result folds into the matmul as a `fused_epilogue` attribute. Multi-use cases are blocked to preserve behaviour. This is the canonical "matmul + bias + activation" optimization that matters most for transformer-shaped workloads.

Target-aware vector-width clamping: apply-schedule clamps the user's vectorize-width hint against the ISA (AVX2 fp32: 8; AVX-512 fp32: 16) and records it as `tile.vector_width`. Tile-specific algebraic canonicalization handles `add(x, zeros) → x` and `mul(x, ones) → x` (standard canonicalize doesn't know `tile.elementwise "zeros"`).

Parallel-loop promotion: `parallel tile_grid` flips the outer loop nest from sequential `scf.for` to parallel `scf.forall`. Tile-size selection is schedule-driven today; autotuning is on the umbrella roadmap. OpenMP runtime hookup is the next milestone.

The pipeline currently terminates by emitting x86-64 AVX2 assembly on disk via `llc`. Lit covers each stage; one end-to-end test pins the full chain. Deliberately deferred: an LLVM ORC JIT to load and execute in-process, plus a Python ctypes harness for the NumPy equivalence check. Both are scoped on the roadmap (the dev machine is arm64, so the perf comparison vs OpenBLAS sgemm needs an actual x86 box).