MLIRArchOpt

MLIRArchOpt is an experimental hardware-aware optimization framework for MLIR.

The goal is to expose target and microarchitectural information earlier in the compilation pipeline, while MLIR still preserves high-level structure such as loop nests, memory accesses, reductions, iteration spaces, and data layouts.

Instead of relying only on late LLVM optimization, MLIRArchOpt aims to use LLVM target information and microarchitectural analysis to guide structural transformations directly at the MLIR level.

Structured MLIR
      |
      v
Program Analysis
      +
Target / Hardware Model
      |
      v
Optimization Planner
      |
      v
Target-aware MLIR
      |
      v
LLVM

Long term, the project is intended to combine:

• structured loop and memory analysis,
• LLVM target information,
• cache and hardware topology,
• vectorization and unrolling decisions,
• tiling and loop transformations,
• analytical cost models,
• speculative lowering,
• LLVM MCA feedback,
• runtime benchmarking,
• learned cost models and reinforcement learning.

Current Status

MLIRArchOpt is currently in early development and performs analysis only.

The current mopt tool can analyze scf.for loops and extract:

• loop depth,
• parent-loop presence,
• static bounds,
• loop step,
• trip count,
• load/store counts,
• arithmetic operation counts,
• multidimensional memory accesses,
• induction-variable usage.

It also performs simple affine reconstruction of memory indices relative to the current induction variable:

i       -> 1*iv + 0
i + 1   -> 1*iv + 1
i - 1   -> 1*iv - 1
2 * i   -> 2*iv + 0

Loop-invariant dimensions are tracked separately, which allows nested accesses such as:

A[i, j]

when analyzing j:

dim 0 -> invariant
dim 1 -> 1*iv + 0

The analysis is connected to LLVM's native TargetMachine and TargetTransformInfo. It can report the selected triple, CPU, data layout, register widths, load/store vector width, and cache information. Loop reports use the fixed vector-register width to derive a natural lane count from the widest memory element.

The current test suite includes:

• linear element-wise loops,
• shifted accesses,
• strided accesses,
• nested 2D loops,
• transpose,
• 1D and 2D stencils,
• dot-product reductions,
• matrix multiplication,
• dynamic loop bounds,
• non-unit loop steps,
• nested memory effects.

Direction

The next major pieces are:

• more precise alias and dependence analysis,
• an explicit loop-nest representation,
• target-aware unrolling and vectorization cost models,
• actual loop transformations,
• LLVM MCA-guided candidate evaluation.

A key long-term idea is to temporarily lower optimization candidates, analyze them through LLVM MCA, and use the resulting microarchitectural feedback to modify the original structured MLIR.

MLIR candidate
      |
temporary lowering
      |
LLVM / MCInst
      |
LLVM MCA
      |
microarchitectural feedback
      |
structured MLIR transformation

MLIRArchOpt is designed as a generic MLIR optimization framework and is independent from any specific frontend.

Tensorium_lang is planned as a future real-world proof of concept and benchmark platform.

Build

MLIRArchOpt requires LLVM built with MLIR support.

cmake -G Ninja \
    -S . \
    -B build \
    -DMLIR_DIR=/path/to/llvm-project/build/lib/cmake/mlir \
    -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

cmake --build build -j

Run:

./build/mopt tests/01_linear.mlir

Dump the MLIR module after the analysis pipeline:

./build/mopt --dump-ir tests/01_linear.mlir

Inspect the LLVM target model used for future cost decisions:

./build/mopt --dump-target-info tests/01_linear.mlir
./build/mopt --dump-target-info \
    --target-triple=arm64-apple-darwin \
    --mcpu=apple-m2 \
    --mattr=+neon \
    tests/01_linear.mlir

Without explicit target options, mopt uses LLVM's host triple and detected CPU. Cross-target triples are limited to the backends compiled into LLVM. Each loop report also contains the fixed vector-register width, the widest memory element, the natural vector factor, and a factor capped by the static trip count. The vector plan classifies legal loops as candidates, rejects proven dependences and unsupported reductions, and keeps unresolved aliasing or memory effects in the unknown state. Memory cost and tail handling are later planning stages.

Run the LIT regression suite:

cmake --build build --target check-mopt

The test configuration discovers lit from PATH and, on Homebrew, finds FileCheck in the versioned llvm@20 formula automatically. Their locations can also be supplied explicitly:

cmake -S . -B build \
    -DMLIR_DIR=/path/to/llvm-build/lib/cmake/mlir \
    -DMOPT_LIT_EXECUTABLE=/path/to/lit \
    -DMOPT_LLVM_TEST_TOOLS_DIR=/path/to/llvm-tools/bin

Use -DMOPT_INCLUDE_TESTS=OFF when configuring a build that does not need the regression target.

Status

Experimental — early development.

No transformations, hardware model, MCA integration, autotuning, or machine-learning components are implemented yet.