In my previous MLIR compiler project, I built a small tensor compiler using the MLIR framework. While working on it, I realized how much complexity the framework handles for me, from lowering operations through existing compiler infrastructure to generating executable code. This made me curious about what happens underneath these abstractions, particularly when compiling for custom hardware rather than a conventional CPU. For this project, I want to explore two things: how AI

This analysis evaluates the sequential performance impact of optimization passes done on a 2048 x 2048 floating-point matrix multiplication workload. The goal of this analysis is to measure the execution speedups, look at how these changes affected CPU cache behavior, and see what further adjustments can be made to improve performance Hardware Specs The following analysis was run on the following environment and hardware specs: Host Processor: Apple M1 Pro (10 cores: 8 perfor

In this article, I am expanding the basic pipeline from the previous article to support a Linear Layer (the foundational building block of modern neural networks). At the hardware level, this workload is driven by a GeMM (General Matrix Multiply) operation, traditionally defined as: C ← αAB + βC To achieve this, I added two new operations to the compiler: relu and matmul. Since relu shares a similar element-wise structure to the 'add' operator covered in Part 1, this article

MLIR Lowering Pipeline Lowering Strategy (High-Level Overview) The lowering pipeline looks like this: ONNX graph -> custom mlir dialect -> tensor (value) -> memref (memory) -> llvm -> JIT Full code for this article is available here This article's focus is only building an end-to-end skeleton that takes a high-level ONNX model and lowers it through progressively more concrete representations until it executes via a JIT engine. I kept the initial scope to scalar and 1D vector