If you’re unfamiliar with concepts such as SCoPs, iteration domains, schedules, access functions, tiling, or dependence analysis, I’d recommend reading my previous article, Understanding Polyhedral Compilation, where I explain these ideas in detail. This will make the rest of this article much easier to follow.

Before we dive further, let’s briefly recap the traditional polyhedral compilation workflow.

At a high level, polyhedral optimization was not a single pass living entirely inside the compiler. Instead, it involved multiple stages, each responsible for a different task.

The first step was identifying a region of code that could be represented in the polyhedral model. These regions, known as Static Control Parts (SCoPs), contain loop nests and memory accesses that can be expressed using affine functions.

Once a valid SCoP was identified, the optimization problem was translated into a mathematical representation consisting of iteration domains, schedules, and access functions.

Then the next step was the scheduling stage where they analyzed this representation and searched for a better execution order. This is where transformations such as loop interchange, tiling, fusion, and skewing were determined. The goal here was to improve locality, expose parallelism, and reduce communication between different parts of the computation.

After a new schedule was found, the transformed mathematical representation had to be converted back into executable code. A code generator would scan the transformed iteration space and produce the final loop nest, including any boundary conditions required to preserve correctness.

Conceptually, the workflow looked something like this:

LLVM IR
↓
Extract affine loop nest (SCoP)
↓
Build polyhedral representation
↓
Compute an optimized schedule
↓
Generate transformed loop nest
↓
Continue compilation

Now the problem was that all these tools were independent of each other and were used at different times. This independence is exactly where the problems started.

Before looking at how MLIR solves them, let's first understand the major problems of the traditional polyhedral workflow.

Problems in Polyhedral Compilation

1. The extraction-transformation-reimport problem

This is one of the fundamental problems and it affects everything else around it. Now to understand this clearly, we need to know how the compiler’s internal representation looks like.

When LLVM compiles our C code, it converts it into something called LLVM IR, which is basically an internal language that the compiler uses to optimize our code. All the LLVM’s optimizations operate on this IR. The reason this IR is so important is because it carries important information like types, variable names, control flow, and everything the compiler knows about your program.

Now there are a couple of things that happen when Polly runs :

1. Extraction : Now we know Polly’s job is to find the loop nests. So when Polly scans the LLVM IR and finds an affine loop nest it extracts it. Now to hand it to Pluto (scheduler), it has to first convert this loop from LLVM IR into a polyhedral mathematical representation which basically consists of iteration domain, access functions, and dependence constraints. Now this conversion is the main problem, because we lose information here. Some information that exists in the LLVM IR simply doesn’t fit into the polyhedral model and because of that it gets dropped.

2. Transformation : Now that after the conversion Pluto receives the mathematical representation and it runs the ILP on it. It finds the best schedule and produces a transformed polyhedron. Then CLooG comes in and scans the polyhedron and produces an optimized C code. At this point the loop exists as a piece of string - a C code string.

3. Reimport : At the end Polly takes the C code string and feeds it back to the compiler. Now again the compiler has to parse it, build the LLVM IR, and figure out how to connect it back to the surrounding code. This honestly is the most painful part.

The problem is the compiler had already built up a careful understanding of your program, it knew which variables were live, which values were constant and what the surrounding flow looked like.

2. Targeting multiple hardware backends was painful

This problem became even more critical when ML workloads became important. A matrix multiplication in a neural network needs to run efficiently on CPUs, GPUs, and TPUs but with classical tools, each target required a separate pipeline.

What I mean by a separate pipeline is basically

For CPU, the workflow was :

Loop → Polly → Pluto → CLooG → C code → LLVM → x86 binary

For GPU, CLooG produces C code but GPUs need CUDA. So you needed a completely different tool :

Loop → some GPU polyhedral tool → CUDA code → nvcc → GPU binary

And similarly for TPU also the hardware is completely different. So as you can see there was no standard polyhedral tool that targeted it at all.

3. Interleaving passes was impossible

Now this might be the most subtle problem but in some ways it is the most damaging for real world performance.

See modern compilers don’t optimize our programs in one big step. They run hundreds of small passes, each one making the code a little better, and more importantly each one building on what the previous pass found. This interleaving is what makes today’s compilers so powerful.

For example a real optimization might look like this :

constant propagation        ← figures out that N=64 in this context
    ↓
loop bounds simplification  ← simplifies "i < N" to "i < 64"
    ↓
loop tiling                 ← now tiles with knowledge that N=64
    ↓
vectorization               ← uses the tiled structure to apply SIMD
    ↓
register allocation         ← allocates registers knowing the vector width

Now lets understand what happens when polyhedral optimization comes in this pipeline :

constant propagation
    ↓
loop bounds simplification
    ↓
STOP — extract loop — leave compiler — run Pluto -
run CLooG — get C code — re-enter compiler — re-parse
    ↓
vectorization
    ↓
register allocation

That hard STOP in the pipeline destroys the information flow in both the directions.

The result is that each pass is now working with less information than it could have, and the overall optimization is weaker than it could have been.

So till here we know what the problem is with the Polyhedral Compilation. It’s not that Pluto’s scheduler was weak or CLooG is generating bad code, in fact these tools are mathematically very powerful. The real problem was about the architecture.

Polyhedral compilation existed outside the compiler instead of inside it, and every time the compiler had to perform polyhedral transformation, it had to leave the compiler, do the things that I explained and regenerate the code again.

At the same time, machine learning workloads were rapidly changing compiler requirements.

Now compilers did not just target CPUs. They had to lower computations across GPUs, TPUs, tensor accelerators, vector units, and domain-specific hardware, all while preserving high-level information like tensor semantics, parallel dimensions, and memory layouts for as long as possible.

Traditional compiler IRs like LLVM IR were simply too low level for this.

And this is exactly the problem MLIR was built to solve.

What is MLIR and why was it built

As I mentioned earlier traditionally we only had one IR layer. That worked extremely well for languages like C/C++ because :

• the abstraction level was relatively low

• loops/maps/pointers were still visible in LLVM IR

• optimization goals were mostly CPU-oriented

But the modern systems evolved and now the compiler had to handle things like :

• tensor algebra

• neural networks

• GPU kernels

• TPUs

• sparse tensors

• vector hardware

• domain-specific languages

• distributed execution

• polyhedral transformations

• quantization

• graph-level optimizations

Trying to represent all of this directly in LLVM IR became painful. The reason it is painful because this stuff is too high level and LLVM IR was intentionally low level. Let us understand this with an LLVM IR example :

%1 = load float, float* %ptr
%2 = fmul float %1, %1
store float %2, float* %out

As you can see, at this level :

• tensor semantics are gone

• loop structure is flattened

• matrix multiplication no longer looks like matrix multiplication

• high-level information disappears too early

This causes a huge issue because many optimizations need high-level structure.

For example:

• tensor fusion

• operator fusion

• loop tiling

• layout transformations

• hardware mapping

• dependence analysis

All become much harder once lowered fully to LLVM IR and that is where MLIR comes into play.

What is MLIR ?

The key idea of MLIR is simple, “Instead of having ONE IR for the whole compiler, allow MANY IR levels to coexist.” That is literally what the name means Multi-Level Intermediate Representation. So instead of forcing everything into one representation, MLIR allows :

• high-level IRs

• mid-level IRs

• low-level IRs

• hardware-specific IRs

all inside the same infrastructure.

The crucial thing to understand here is MLIR is not a compiler. It is a framework for building compilers. It basically gives you tools, the infrastructure, and the conventions so that when Google builds their TPU compiler or when Apple builds their ML compiler, they are both building on the same foundation. Now this allows their IRs to talk each other, their passes can be shared because their tools are compatible.

One way to understand MLIR is like a shared platform, the way Android is a shared platform for phone manufactures. Each manufacturer builds their own phone, but they share the underlying OS, MLIR is the underlying OS for compiler infrastructure.

Why this matters for polyhedral compilation

Now remember the problems that we had came down to the same root cause - that classical polyhedral tools lived outside the compiler and spoke a different language. But MLIR fixes this by giving polyhedral compilation its own native IR level - the affine dialect. We will discuss this dialect in more detail but remember that it lives inside the compiler with everything else. Here there is no need for extraction, reimport and translation.

What are Dialects and Operations

Dialects and Operations are basically the concepts that make MLIR what it is.

Lets us start with an Op (Operations) is : An Op (operation) is the basic building block of MLIR. Everything in MLIR is an op. A Loop is an op. An Addition is an op. A function definition is an op. A matrix multiply is an op.

Think of an op as a self-contained unit of computation that has :

• A name that identifies what it does

• Inputs (called operands)

• Outputs (called results)

• Attributes (fixed properties known at compile time)

• A region (optional — some ops contain other ops inside them)

Lets take an example of a simple addition op :

%result = arith.addi %a, %b : i32

Now here as we can see :

• %result — is the output

• arith.addi — the name of the op (addi means integer addition, in the arith dialect)

• %a, %b — these are the inputs

• i32 — this specifies the type of inputs which are 32-bit integer

A loop op looks like this :

affine.for %i = 0 to 10 {
    // other ops live inside here
}

Now this op has no output, its input is the loop bounds, and it has a region - the loop body, which contains other ops inside it.

The thing to understand is that ops are composable. We build programs by nesting ops inside ops inside ops. One way to understand this is, lets say a function contains a loop op, the loop op contains arithmetic ops. This nesting is how MLIR represents complex programs.

Now dialects

Think of dialect as a collection of ops that belong together, plus the rules about how those ops behave.

It is basically like a vocabulary for a specific domain. What I mean by that is, the english language has specialized vocab for medicine, law and engineering. A doctor and a lawyer both speak English, but they use different specialized terms of their domain. Dialects in MLIR work the same way.

Each Dialect defines ops that make sense for its domain :

• The arith dialect defines arithmetic ops - addition, subtraction, multiplication, comparison

• The affine dialect defines ops for affine loop nests - affine.for, affine.if, affine.load, affine.store

• The linalg dialect defines named linear algebra ops - linalg.matmul, linalg.conv2d

• The llvm dialect defines ops that map directly to LLVM IR instructions

• The gpu dialect defines ops for GPU computation

The important thing to notice here is the naming convention, every op is prefixed with its dialect name. affine.for is the for op in the affine dialect. linalg.matmul is the matmul op in the linalg dialect. This makes it immediately clear which dialect an op belongs to.

Why multiple dialects instead of one

The reason we have multiple dialects is because earlier we only used to have one IR level which was LLVM IR and it was too low-level and we were missing out on high-level optimizations.

So now different dialects represent different levels of abstraction and that is why we have multiple dialects.

Now at the highest level a matrix multiple can be best represented as a single linalg.matmul op. It’s clean, it carries semantic meaning, and it’s easy to apply high level optimizations to it. But at the low level, that same matrix multiply needs to be broken down into explicit loops, memory accesses, and arithmetic, because that’s what the hardware actually executes.

Now since we have multiple dialects we can represent the same computation at multiple levels simultaneously and gradually transform it from one level to the next.

Lets take an example to understand what I mean by that :

High level - linalg dialect:

linalg.matmul ins(%A, %B) outs(%C)

One op. Clean. Carries the full semantic meaning “this is a matrix multiply.”

Mid level - affine dialect:

affine.for %i = 0 to %N {
    affine.for %j = 0 to %N {
        affine.for %k = 0 to %N {
            %a = affine.load %A[%i, %k]
            %b = affine.load %B[%k, %j]
            %c = affine.load %C[%i, %j]
            %mul = arith.mulf %a, %b
            %add = arith.addf %c, %mul
            affine.store %add, %C[%i, %j]
        }
    }
}

Explicit loops. This is where polyhedral analysis and tiling happen.

Low level - llvm dialect:

// Individual load instructions, pointer arithmetic,
// SIMD vector operations, branch instructions

Hardware-level ops. Ready for code generation.

All three represent the same computation. The compiler moves from one level to the next through a process called lowering.

How lowering works

Lowering essentially is the process of taking ops from a higher level dialect and replacing them with equivalent ops from a lower level dialect. We are not changing what the program computes, we are just changing how it’s represented, making it more concrete and closer to what the hardware actually executes.

For example the convert-linalg-to-affine-loops pass finds every linalg.matmul op and replaces it with the explicit affine.for loop nest we showed above. The lower-affine pass finds every affine.for and replaces it with a more basic scf.for (structured control flow). The convert-scf-to-cf pass replaces structured loops with basic branch instructions.

Each step makes the representation more explicit and less abstract.

The full lowering stack for matmul

Here is what the complete journey looks like for a matrix multiply going from PyTorch all the way to hardware:

PyTorch: model(x)
    ↓  torch.compile
torch dialect: torch.aten.mm
    ↓  conversion pass
linalg dialect: linalg.matmul
    ↓  tiling pass (polyhedral!)
linalg dialect: tiled linalg.matmul
    ↓  lowering pass
affine dialect: affine.for loops    ← We are here
    ↓  affine optimization passes (interchange, fusion)
affine dialect: optimized affine.for loops
    ↓  lowering pass
vector dialect: vector.contract ops (SIMD)
    ↓  lowering pass (choose target)
llvm dialect → x86 binary (CPU)
nvvm dialect → PTX code (NVIDIA GPU)
rocdl dialect → GPU binary (AMD GPU)

If you look at that stack carefully, the polyhedral world we’ve been talking about lives in the affine dialect section. Everything above it is higher level abstraction coming down toward it. Everything below it is lower level abstraction moving toward hardware.

Lets take one more example of lowering and see how the dialects connect with each other :

This is MLIR’s multi-level lowering pipeline for a matrix multiplication. High-level operations such as linalg.matmul are progressively lowered through different dialects, each representing the computation at a different level of abstraction. Polyhedral optimizations such as tiling, loop interchange, fusion, and dependence analysis are performed in the Affine dialect, where iteration domains and memory accesses are explicitly represented. Once optimized, the same transformed program can be lowered to multiple hardware targets (CPU, GPU, TPU) without requiring separate polyhedral optimization pipelines for each backend.

Why this is so much better than classical tools

In the classical polyhedral compilation, remember the problem, the polyhedral tool lived outside the compiler, spoke a different language, and required extraction and reimport.

In MLIR, lowering solves this completely. Every step in that stack above is just a pass operating on MLIR IR. There is no external tool. There is no extraction. There is no reimport.

Now till now we know MLIR is a framework of dialects, each one representing computation at a different level of abstraction, and that lowering moves code from one dialect to the next. But what exactly is the affine dialect, what does it look like, and how does it connect to everything I wrote about in my previous blog - iteration domains, schedules, and access functions? That is what we will be discussing next.

What is the affine dialect and why it exists

Now if you remember from my previous blog that the polyhedral compilation only works on affine loops, which means loops where bounds and array accesses are linear functions of the loop variables. The reason for that was that expressions create flat geometric shapes that the compiler can reason about mathematically.

Now the problem that we had in LLVM IR was that there was no way to look at a loop and immediately know if its affine or not. LLVM IR is too low level - it represents loops as basic blocks and branch instructions. To do polyhedral analysis at the LLVM level, Polly had to work hard just to figure out which loops were even candidates for optimization.

This problem is now solved by the affine dialect. The affine dialect solves this by making affineness a guarantee built into the IR itself. If a loop is expressed using affine.for, the compiler already knows it’s affine by definition. You can’t write a non-affine loop using affine dialect ops. The dialect simply doesn’t allow it.

This is the core reason affine dialect exists: to give polyhedral compilation a native home in the compiler where the affine property is enforced structurally, and not discovered after.

What the affine dialect covers

The affine dialect is basically a collection of ops specifically designed for affine loop nests. It covers :

• Loop control — affine.for and affine.if

• Memory access — affine.load and affine.store

• Mathematical mappings — called affine maps

Everything in the affine dialect is guaranteed to be analysable by polyhedral tools. The moment our code is in the affine dialect, the compiler can immediately start asking polyhedral questions - what are the dependencies, what’s the best schedule, where should we tile - without any prior analysis to check eligibility.

If you remember the three mathematical objects from the previous blog, in the affine dialect those are represented as :

• Iteration domain — represented by affine.for bounds

• Schedule — reflected by the nesting order of affine.for ops (though schedules are more generally represented as ordering functions over iterations)

• Access function — represented by affine maps in affine.load and affine.store

Now let us look at some of the ops in the affine dialect

1. affine.for

affine.for is the affine dialect’s loop op. It represents exactly the kind of affine loop we’ve been writing throughout my previous blog.

The basic structure looks like this :

affine.for %i = 0 to 10 {
    // loop body
}

Here %i is the loop induction variable, this is the i from our iteration domain.

0 is the lower bound. 10 is the upper bound.

The loop body contains other ops that execute for each value of %i.

A nested loop looks like this :

affine.for %i = 0 to %N {
    affine.for %j = 0 to %N {
        // loop body
    }
}

This is our 2D iteration domain 0 ≤ i < N, 0 ≤ j < N expressed directly as IR.

Now the nesting of the two affine.for ops encodes the schedule i.e %i is the outer loop and %j is the inner loop. If we want to interchange the loops, we can just swap the nesting order.

The important thing to remember here is that the bounds must be affine. You can’t have an affine.for with non affine bounds. The upper and lower bounds of an affine.for must be affine functions of surrounding loop variables or constants.

Lets take an example :

This is valid since lower bound linearly depends on %i

affine.for %j = %i to %N {   // lower bound depends linearly on %i

But this is not allowed in the affine dialect :

affine.for %j = 0 to %i * %i {   // quadratic — not affine

The dialect enforces affineness at the IR level. This is what makes polyhedral analysis possible without any preliminary checking.

2. affine.if

affine.if is the conditional op in the affine dialect. It allows conditional execution inside the affine loops, but with an important restriction, the condition must be an affine constraint, meaning it must be a linear inequality involving loop variables.

Lets take an example to understand this.

Generally inside a nested loop this if condition is written like this :

for(i=0; i<N; i++)
{
    for(j=0; j<N; j++)
    {
        if(i <= j)
        {
            ...
        }
    }
}

But the same thing in MLIR is written like :

affine.for %i = 0 to %N {
  affine.for %j = 0 to %N {

    affine.if affine_set<(i,j):(j - i >= 0)>(%i,%j) {

      ...
    }
  }
}

Now the thing to focus on is the affine.if op.

affine.if affine_set<(i,j):(j - i >= 0)>(%i,%j)

Think of it as :

affine_set<(dimensions):(constraints on those dimensions)>(actual values)

These are symbolic variables used inside the affine set definition. They are not the actual MLIR values.

Think of them like variables in a math equation.

For example:

(i,j)

means: I am defining constraints involving two dimensions called i and j.

Coming to the constraint

(j - i >= 0)

This is the affine constraint.

Equivalent to:

j >= i

This defines the valid region.

Geometrically it means All points on or above the diagonal j=i

affine_set<...>

Putting the above parts together:

affine_set<(i,j):(j-i>=0)>

means: Create a set of all integer points (i,j) that satisfy j-i≥0.

Actual Values

(%i,%j)

Now we get to the important part.

(%i,%j)

These are the actual MLIR SSA values.

Example:

affine.for %i = 0 to 100 {
  affine.for %j = 0 to 100 {

    affine.if affine_set<(i,j):(j-i>=0)>(%i,%j) {
      ...
    }

  }
}

Here:

symbolic dimension i  ← actual loop variable %i
symbolic dimension j  ← actual loop variable %j

The compiler substitutes:

i = %i
j = %j

and checks whether:

%j - %i >= 0

is true or not.

The most important thing to remember is the constraint j - i ≥ 0 is a linear inequality and it defines a half-space in the iteration domain. This is exactly the kind of condition polyhedral tools can reason about. The compiler can look at this and say “for these iterations the condition is true, for those iterations it’s false” purely from the geometry.

3. Affine Maps

An affine map is the mathematical heart of the affine dialect. It’s actually a function that maps a set of input dimensions to a set of output dimensions using only affine expressions. The notation look like this :

affine_map<(d0, d1) -> (d0, d1 + 1)>

Here there are two input dimensions d0 and d1, which produce two output dimensions d0 (unchanged) and d1 + 1 (shifted by one).

Lets understand this in detail with an example :

First forget MLIR for a minute

Suppose you have this loop:

for(int i = 0; i < N; i++) {
		A[i+1] = A[i] + 1;
}

Let’s look at one iteration:

i = 0  → accesses A[0] and A[1]
i = 1  → accesses A[1] and A[2]
i = 2  → accesses A[2] and A[3]

Notice what’s happening here.

The loop variable is:

i

But the memory location being accessed is:

i + 1

So there is a function:

iteration point → memory location

which is:

i → i + 1

This is exactly what an affine map represents.

Think of affine maps as coordinate translators, suppose someone asks : “At iteration i = 5, which memory location are you touching?”

This answer is :

i → i + 1
5 → 6

The affine map is simply the rule that performs this translation.

Let us take a 2D example

Now consider:

for(int i = 0; i < N; i++){
	for(int j = 0; j < N; j++){
			A[i][j+1]=0;
	 }
}

The iteration space is:

(i,j)

For example:

(2,3)

means:

i=2
j=3

Which memory location do we touch?

A[2][4]

because:

(i,j) → (i,j+1)

This transformation is represented in MLIR as:

affine_map<(d0,d1) -> (d0,d1+1)>

Affine maps are how the compiler represents access functions precisely and mathematically inside the IR. Because since these are linear functions, the compiler can directly do algebra on them and compute their intersection, check if two accesses touch the same memory location, and then derive the dependency vectors.

Common affine map patterns

Identity access — A[i][j]:

affine_map<(d0, d1) -> (d0, d1)>

Shifted access — A[i][j-1]:

affine_map<(d0, d1) -> (d0, d1 - 1)>

Strided access — A[2*i][j]:

affine_map<(d0, d1) -> (d0 * 2, d1)>

Tiled access — A[ii + i][jj + j]:

affine_map<(d0, d1, d2, d3) -> (d0 + d2, d1 + d3)>

That last one is the tiled matmul access pattern — four loop variables (tile indices ii, jj and intra-tile indices i, j) mapping to a 2D array location.

4. affine.load and affine.store

affine.load and affine.store are the memory access ops in the affine dialect. They are how iterations read from and write to arrays.

A load looks like this :

%val = affine.load %A[%i, %j] : memref<?x?xf32>

Here, a value from array %A at position [%i, %j] is loaded, where the result is a 32-bit float.

You might ask why not just use load ?

LLVM already has load instructions. Why do we need affine.load?

Because Affine dialect wants memory accesses to be mathematically analyzable.

For example:

affine.load %A[%i + %j]

The compiler immediately knows:

Access Function:
(i,j) → i+j

which is affine.

Remember what we learned about affine maps?

Iteration Point
      ↓
Memory Location

affine.load is where that mapping is actually used.

A store looks like this:

affine.store %val, %C[%i, %j] : memref<?x?xf32>

Reading this: store the value %val into array %C at position [%i, %j].

Why Polyhedral Analysis Cares

Imagine:

A[i][j]=A[i][j-1]+1;

In MLIR:

%prev = affine.load %A[%i, %j - 1]

affine.store %new, %A[%i, %j]

Compiler now sees:

Load:
(i,j) → (i,j-1)

Store:
(i,j) → (i,j)

Immediately it can ask:

Can a store from one iteration become a load in another iteration?

This is exactly dependence analysis.

The indices [%i, %j] in a load or store are not just arbitrary expressions, they must be affine maps. Under the hood, every affine.load and affine.store carries an explicit affine map that describes the access pattern.

So when we write:

%val = affine.load %A[%i, %j - 1]

MLIR internally represents this as:

%val = affine.load %A[affine_map<(d0,d1)->(d0, d1-1)>(%i, %j)]

The affine map (d0, d1) -> (d0, d1-1) is the access function from my previous blog - (i,j) → (i, j-1). It’s stored explicitly in the IR, not inferred from text.

Why this matters for dependence analysis

Because every affine.load and affine.store carries an explicit affine map, the compiler can inspect any two memory ops and immediately ask “can these access the same location?” It compares the two affine maps mathematically.

For example consider these two ops inside a loop:

affine.store %val, %A[%i, %j]        // writes A[i][j]
%x = affine.load %A[%i, %j - 1]     // reads A[i][j-1]

The compiler compares the maps:

• Store map: (i,j) → (i, j)

• Load map: (i,j) → (i, j-1)

It asks: “is there any (i,j) where these produce the same output?” That means solving (i, j) = (i, j-1) which gives j = j-1 — impossible. So these two ops never access the same location — no dependence.

Now consider:

affine.store %val, %A[%i, %j]        // iteration (i,j) writes A[i][j]
%x = affine.load %A[%i, %j + 1]     // iteration (i,j) reads A[i][j+1]

The compiler asks: “is there any pair of iterations where the store and load touch the same element?” That means: does (i₁, j₁) = (i₂, j₂ + 1) have a solution within the loop bounds? Yes because when i₁ = i₂ and j₁ = j₂ + 1. Dependence exists, distance vector will be (0, 1).

This is basically our Omega test from my previous blog, but now it’s running natively inside the compiler on IR nodes, and not on extracted text handed to an external tool.

Lets take a complete example to summarise all of this :

// for (i=0; i<N; i++)
//   for (j=1; j<N; j++)
//     A[i][j] = A[i][j-1] + 1

affine.for %i = 0 to %N {
    affine.for %j = 1 to %N {
        %val = affine.load %A[%i, %j - 1]   // access function: (i,j) → (i, j-1)
        %c1 = arith.constant 1 : i32
        %new = arith.addi %val, %c1
        affine.store %new, %A[%i, %j]        // access function: (i,j) → (i, j)
    }
}

Every polyhedral concept is present here:

• Iteration domain — encoded in the affine.for bounds: 0 ≤ i < N, 1 ≤ j < N

• Schedule — encoded in the nesting order: i outer, j inner

• Access functions — encoded in the affine maps of affine.load and affine.store

• Dependence — derivable by comparing the two affine maps mathematically

The compiler has everything it needs to run polyhedral analysis, apply tiling, check legality, and generate optimized code, all natively, without leaving the IR, without external tools, without extraction or reimport.

This is why the affine dialect exists.

Conclusion

Polyhedral Compilation is a mathematically powerful technique, but its traditional implementation had a fundamental architectural limitation, which was that the tools lived outside the compiler. Every time a transformation was needed, the compiler had to extract the loop, hand it to an external tool, and reimport the result. During this whole process there was information loss at every boundary, passes could not interleave, and targeting multiple hardware backends required completely separate pipelines.

MLIR addressed these issues by making polyhedral analysis native to the compiler IR through the affine dialect.

The three objects that polyhedral compilation depends on - iteration domains, schedules, and access functions - are no longer computed from the code after the fact. They are encoded directly in the IR. Every affine.for bound is an iteration domain. Every nesting order is a schedule. Every affine.load and affine.store carries its access function as an explicit affine map. This means the compiler can perform dependence analysis, apply transformations, and generate optimized code without ever leaving the IR or crossing a tool boundary.

This is what makes MLIR’s approach to polyhedral compilation fundamentally different from what came before, its not better math, but better infrastructure around the same math.

I wrote this as part of my ongoing effort to understand polyhedral compilation and how it fits into modern compiler infrastructure. The goal of this particular post was to build a clear intuition for why classical polyhedral tools had architectural limitations and how MLIR addresses them through the affine dialect and not as a rigorous treatment of the subject, but as an honest attempt to explain the concepts in a way that actually makes sense.

If you notice any mistakes, oversimplifications, or missing context, I’d genuinely appreciate you pointing them out. There is a lot of depth to this topic and I am still working through it.

The core of polyhedral compilation is basically a mathematical framework for analysing and transforming loops in programs. Before diving into the math, let us first understand what problem is this solving.

The Problem It Solves

Modern CPUs are fast but memory is slow. What I mean by that is that when a program runs nested loops like matrix multiplication, the pattern in which you access memory determines if your program is gonna run in 1 second or 10 seconds. The question is : “can a compiler automatically figure out the best loop structure for a given piece of hardware?” That’s exactly what polyhedral compilation does.

Before we dive in I think there are couple of concepts we should be aware about. So lets understand those first.

What is an “Affine Program”?

Now the first and foremost step is to understand an “Affine Program”. Polyhedral compilation works on a restricted but very common class of loops called the affine loops. These have :

1. Loop bounds that are linear functions of outer loop variables or constants (e.g., i = 0 to N, j = i to N)

2. Array accesses that are linear (affine) functions of loop variables (e.g., A[i+j], not A[i*j])

3. No data-dependent control flow inside the loop body

These are basically programs where everything behaves in a predictable, straight-line way (linear).

Example :

Here as you can see everything is linear :

1. i < N → simple

2. j = i to N → depends linearly on i

3. A[i + j] → linear

Everything is just addition, subtraction and constants.

Most scientific, ML, and image-processing kernels (matrix multiply, convolution, stencil computations) fall squarely into this class.

Now you might get a doubt that “why are we restricting to only linear/affine expressions?” The simple answer is that linear program form flat shapes (planes, boxes, cubes). Whereas non-linear bounds would give complex curved surfaces which we can’t evaluate easily.

Why Does This Matter

Computers (compilers) can easily understand and manipulate straight shapes, but not curved ones.

Affine case:

Like a grid or rectangle

You can:

• divide it into blocks (tiling)

• reorder it

• analyze it easily

Non-affine case:

Like a weird curved shape

You can’t:

• divide it cleanly

• reason about dependencies easily

• apply math optimizations safely

The reason we restrict to affine programs only is because they create simple, straight-line patterns that can be analyzed and optimized mathematically.

The Three Mathematical Objects

Now that we know what affine loops are, lets see their representation. Every affine loop nest gets represented as three things :

• Iteration Domain → WHERE computations happen

• Schedule → WHEN computations happen

• Access Function → WHAT memory each computation touches

Let Us Understand All Three Objects In Detail

Iteration domian

Let us take the following loop as an example

Iteration domain basically tells us all (i,j) values where the loops runs.

So : 0 ≤ i < N & 0 ≤ j < N

Think of each iteration as a point in the plane. So you get (0,0), (0,1), ……, (N-1,N-1). Which will be just a grid of points.

In short, iteration domain means all the points where computation happens.

Schedule

This basically tells us in what order should we execute these points.

The default schedule is

Which means sort by :

1. i

2. then j

Execution order :

which is a row-wise execution.

The transformation that happen like (tiling, interchange, etc.) are just changing of the schedule.

Access Function

Now we ask, when we are at (i,j), which memory location do we access ?

Access function tells us which memory location each iteration touches. The reason Iteration functions are important is because this is where dependencies come from.

The access function maps an iteration point to an array element.

A[i][j] is the function (i,j) → (i,j).

A[i][j+1] is (i,j) → (i, j+1).

Example:

(i, j) reads A[i][j-1]

Which was written by:

(i, j-1)

So dependency:

(i, j-1) → (i, j)

This is how the compiler knows:

1. what must come before what

2. what transformations are safe

Dependency Analysis

Now before transforming loops, the compiler must ensure it doesn’t break the required execution order between iterations. Basically it means if I reorder loops, the program should still produce the correct result.

That’s it, the entire topic revolves around this one thing.

The reason modern compiler reorder loops is to make programs run faster and they do this by :

• parallelizing loops

• tiling loops for cache efficiency

• interchanging loops

• fusing loops

• vectorizing loops

For example the compiler may transform:

for (i=0; i<N; i++)
  for (j=0; j<M; j++)

into:

for (j=0; j<M; j++)
  for (i=0; i<N; i++)

But before doing this the compiler has to make sure it doesn’t change the meaning of the program because some iterations depend on others.

When are Iterations Independent ?

We can understand this using a very simple example :

for (i = 0; i < 4; i++)
   A[i] = 10;

Here each iteration touches a completely different memory location. So no iterations affect each other and the loop can run in parallel. So because of this the compiler can reorder iterations safely.

When do Iterations Depend on Each Other ?

Lets take another example for this :

for (i = 1; i < 4; i++)
  A[i] = A[i-1] + 1;

This might look similar but is very different in terms of how memory is accessed. Lets understand this in more detail.

Iteration i = 1

A[1]=A[0]+1;

Touches:

• READ A[0]

• WRITE A[1]

Iteration i = 2

A[2]=A[1]+1;

Touches:

• READ A[1]

• WRITE A[2]

The important thing to notice here is :

1. At iteration i = 1, we write A[1]

2. At iteration i = 2, we read A[1]

So both the iterations touch the same memory location. And because of this it creates a relationship :

i = 2 depends on i = 1

because iteration 2 needs the value produced by iteration 1.

Dependence Vector

Now that we know that some iterations are dependent on each other, dependence vector tells us how far apart are these dependent iterations.

Lets take this example again :

for (i = 1; i < 5; i++)
    A[i] = A[i-1] + 1;

We already know that iteration i=2 depends on iteration i=1 because i=2 reads A[1] which was written by i=1.

When iteration q depends on iteration p (meaning p must run before q), the dependence vector is simply:

d = q - p

It’s the difference in coordinates between the two iterations. That’s it. For the loop above, p = 1 and q = 2, so:

d = 2 - 1 = (1)

The vector (1) means: “there is a dependence that jumps exactly 1 step forward in i.” For all pairs in this loop:

• i=2 depends on i=1 → d = (1)

• i=3 depends on i=2 → d = (1)

• i=4 depends on i=3 → d = (1)

Every dependence has the same distance. The dependence vector is uniform here.

Dependence Direction Vector

We know dependence vector tells us the exact numeric distance i.e +1 or +2 or (0, +1) etc.. but dependence direction vector tell us only the direction i.e forward ? , backward ? or same ?

Instead of numbers, it uses symbols :

1. “ < “ means Forward

2. “ > “ means Backward

3. “ = “ means same

Lets take a simple example to understand this clearly :

for (i = 0; i < N; i++)
  for (j = 1; j < M; j++)
    A[i][j] = A[i][j-1] + 1;

At iteration (i,j) it reads A[i][j-1] which was written by (i,j-1). So dependence is (i,j-1) → (i,j)

Dependence Vector (Consumer - Producer) gives us :

(i,j) — (i,j-1) = (0, +1)

Meaning there is :

1. No movement in i

2. forward movement in j

Why direction vector matter more

Exact distances may change after transformations, but the direction should remain the same for the loop transformation to be legal.

Let us take Legal Loop Interchange :

Example 1 :

Suppose : direction is (=,<)

After interchange is (<,=)

This is still in forward direction, so this is Legal.

Example 2 :

If After interchange it produces this : (>,=) then it basically means a backward dependence which is illegal. Because Consumer executes before Producer.

So in short the Dependence vector tells us “Exactly how far the data flows” and Direction vector tells us “Which way the data flows”. A loop transformation is legal if it preserves the producer-before-consumer ordering, which usually means the transformed dependence direction vectors remain lexicographically forward (not backward).

The Omega Test and Fourier–Motzkin Elimination

So far we have understood dependency analysis conceptually:

• Two iterations depend on each other if they access the same memory location

• At least one access is a write

• The compiler represents accesses mathematically

• Then it checks whether valid iteration pairs exist

But now comes the important question : “How does the compiler actually solve these equations?”

This is where the “geometry” of polyhedral compilation comes into play. Underneath all the high-level compiler transformations is a math proof engine that answers questions like : “Do these constraints have a valid integer solution?”

Lets understand the whole pipeline :

1. Lets start up with loop example

for (i = 1; i < 5; i++)
    A[i] = A[i - 1] + 1;

We already know that Iteration 2 depends on Iteration 1 and that there is a dependence here.

1. What the Compiler Whats to know

The compiler asks “can two different iterations access the same array location?”. To reason this mathematically, it creates two copies of the loop variable :

• i₁ → first iteration

• i₂ → second iteration

Note : The compiler still doesn’t know that there is a dependence.

For dependence : They must access the same location, so compiler writes : i1 = i2 - 1

This equation basically means A value written by one iteration is read by another.

1. Why loop bounds matter

The compiler also knows :

for (i = 1; i < 5; i++)

So :

1 ≤ i1 ≤ 5
1 ≤ i2 ≤ 5

Now the question that compiler asks is do integer values exist satisfying all these equations.

1. Solve it manually

We have :

i₁ = i₂ - 1
1 ≤ i₁ < 5
1 ≤ i₂ < 5

If i2 = 2 then i1 = 1, which is valid. So dependency Exists.

The Entire Compiler Problem is Basically This

It repeatedly asks “Can I find valid integer values?”

If yes : Dependency Exists

If no : No Dependency

Fourier-Motzkin Elimination

This is basically a way of solving those equations by removing variables one-by-one until problem becomes simpler.

Suppose we have:

x + y ≤ 10
x ≥ 2

Rewrite first equation:

x ≤ 10 - y

Now:

2 ≤ x ≤ 10 - y

For this to be possible:

2 ≤ 10 - y

So:

y ≤ 8

Now the problem Fourier-Motzkin faces that it works over REAL numbers, but loops use intergers. This difference matters a lot.

Example :

2x = 1

Over real numbers:

x = 0.5

Valid answer, but loop iterations cannot be:

i = 0.5

Iterations must be integers.

Omega Test Intuition

To solve our previous problem faced by using Fourier-Motzkin, this test is basically a smarter interger-aware elimination algorithm. It extends Fourier-Motzkin while carefully handling integer rules.

Example

Suppose compiler gets:

2i₁ = 2i₂ + 1

Basically means:

even = odd

Which is impossible. The Omega Test detects this quickly.

The Reason this matters is because after this the compiler know if there is any dependence or not. So that it safely parallelize or reorder loops.

Okay till now we know that the compiler builds an iteration domain, detects dependencies and checks if the transformations are legal or not. But the important part that we have to understand is detecting whether a transformation is legal is different from finding the best one.

There are infinitely many valid loop orderings for a given program. The compiler has to figure out which one to pick. That is basically the Scheduling problem.

Scheduling Problem

As I mentioned earlier, a schedule is just a function that assigns a timestamp to every iteration point.

The default schedule for

for i: for j: is θ(i,j) = (i, j)

meaning sort first by “i”, then by “j”

Now imagine if you are allowed to change that function. You can try :

• θ(i,j) = (j, i) → loop interchange

• θ(i,j) = (i/B, j/B, i, j) → tiling

• θ(i,j) = (i+j, j) → skewing

All of these schedules are different but each one visits the same set of points just in different order. This compiler is basically searching through this huge space of possibilities and asking : which one runs faster on this hardware?

Now a valid schedule must satisfy two things simultaneously :

1. Legality : Every dependency has to be respected. If iteration “p” must run before iteration “q”, then the schedule must assign “p” a timestamp that comes before “q”. In short the schedule must keep all dependences pointing “Forward”.

2. Optimality : Among all the legal schedules, pick the one that minimizes execution time. On a modern CPU this mostly means: minimize how often you fetch data from RAM, and maximize how much work you do with data while it’s still in cache. On a multi-core machine it also means: maximize the number of iterations that can run in parallel.

Now the compiler cannot go through all of these options because its not just large - its infinite. So we need to find a better and more optimal way to do it, which is exactly what Pluto provides.

The Pluto Algorithm

Pluto’s central idea is clever and straight forward. Instead of saying “’let me try all the different loop transformations and see which one is fastest” it says : “let me directly search for a schedule that maximizes data reuse, subject to legality constraints - and let the loop transformations fall out as a consequence.”

What Pluto is actually searching for

Pluto is looking for a schedule of the form θ(i,j) = c₁·i + c₂·j + c₀ a linear function of the loop variables. The unknowns are the coefficients c₁, c₂, c₀.

Finding the right coefficients indirectly means finding the right schedule.

For example:

• If c₁=1, c₂=0 → sort by i first → original order

• If c₁=0, c₂=1 → sort by j first → interchange

• If c₁=1, c₂=1 → sort by i+j → skewing

The transformation comes from these coefficients. Pluto doesn’t have a list of “try interchange, try tiling or try skewing”. It just solves for these coefficients and whatever is the solution, will be the transformation.

Lets try to understand a little back story to actually why we are using this Pluto Algorithm.

As I mentioned in the beginning of this blog, today’s CPUs are fast but memory is slow. What I actually mean by that is, whenever a program needs to run, it needs to fetch data. Now there are couple places where it can fetch the data from, it could either be RAM or cache.

Whenever a program needs data from RAM, it first tries to see if that data is already present in the cache.

• If the data is already there → then data is retrieved very fast (cache hit)

• If not → it has to go all the way to RAM → which is slow (cache miss)

So the biggest goal in loop optimization is:

“Use data again before it gets kicked out of the cache.”

This is what Pluto tries to optimize.

Let us understand using an example what I mean by “Use data again before it gets kicked out of the cache”

Example 1 : Consider this simple loop

for (i = 0; i < 3; i++) {
    for (j = 0; j < 3; j++) {
        use(A[i]);
    }
}

For i = 0, notice that

use(A[0])
use(A[0])
use(A[0])

The same value A[0] is reused many times immediately.

That is good for cache because once A[0] is loaded, it stays in cache while we keep using it for different iterations as well. Because of this it reduces the time fetching the data.

Example 2 :

for (j = 0; j < 3; j++) {
    for (i = 0; i < 3; i++) {
        use(A[i]);
    }
}

Now the accesses become:

A[0], A[1], A[2],
A[0], A[1], A[2],
A[0], A[1], A[2]

Here as we can see between two uses of A[0], many other values were accessed. Maybe cache already evicted A[0] so if we tried to access A[0] again we would have to go the RAM. That is worse locality.

What Pluto wants :

Pluto basically asks “Can I reorder iterations so reused data is accessed closer together in time?”

Because :

• close together in time = likely still in cache

• far apart in time = probably evicted

So Pluto tries to make reused values happen as soon as possible.

The Cost Function (the actual optimization target) :

The cost function basically means “what number are we trying to minimize of maximize?”

For Pluto it is : Cost = total dependence distance

Smaller cost means:

• producer and consumer iterations execute closer together

• reused data stays in cache

• fewer cache misses

• all of which leads to faster program

So Pluto searches for loop schedules that make this number as small as possible.

How the Compiler Actually Solves It

Now that we understand why Pluto wants better schedules, let’s try to understand how it actually computes them mathematically using ISL (Integer Set Library).

Think of Pluto as an optimization strategy and ISL as the mathematical engine underneath all of this.

When Pluto decides “I want a schedule that minimizes reuse distance.” Then at that point ISL is the thing that actually manipulates the equations, solves the constraints, and computes the schedule.

Let us tie all of this together with an example :

1. Represent Loops mathematically

for (i = 0; i < N; i++)
    for (j = 0; j < N; j++)
        S(i,j);

Now as we know Pluto converts this loop into an iteration space and each iteration becomes a point (i,j). So the entire loop becomes a 2D grid of points.

Lets take N = 3 :

(0,0) (0,1) (0,2)
(1,0) (1,1) (1,2)
(2,0) (2,1) (2,2)

ISL represents this as a polyhedron :

0 ≤ i ≤ N, 0 ≤ j < N

This is the basically the mathematical representation of the loop.

2. Dependencies Become Constraints

Now suppose iteration (i,j) produces a value used by (i, j + 1). That means (i,j) has to be executed before (i,j+1). Otherwise the program will become invalid, this is Pluto encodes as the legality constraint.

3. Pluto Introduces An Unknown Schedule

As we discussed earlier that Pluto doesn’t try to find all the legal loop transformation, instead it solves a linear schedule instead.

Now Pluto assumes an unknown linear schedule:

θ(i,j) = c1i + c2j + c0

The coefficients :

c₁, c₂, c₀

are unknown. Finding these coefficients means finding the execution order.

4. Converting Correctness Into Equations

Now we already know that the Producer must be executed before Consumer.

So Pluto writes :

θ(i , j+1) − θ(i , j) ≥ 1

Now substitute the schedule equation. After substitution we get :

(c1i + c2(j+1) + c0) − (c1i + c2j + c0) ≥ 1

Everything cancels except :

c2 ≥ 1

This is really important because the compiler just transformed program correctness into a linear inequality. ISL is actually really good at solving systems of inequalities like this.

5. Locality Becomes The Optimization Objective

At this point, Pluto has ensured that the schedule is correct, but that alone is not enough. There are many schedules which may satisfy the legality constraints. Now Pluto asks “Among all legal schedules, which one gives the best cache locality?”

This becomes the actual optimization objective.

Consider the slightly modified loop :

for (i = 0; i < N; i++)
    for (j = 0; j < N; j++)
        use(A[i]);

Here you can notice the accessed value only depends on i and not j.

That means :

(i=0,j=0) → A[0]
(i=0,j=1) → A[0]
(i=0,j=2) → A[0]

The same value is reused as j changes.

So reuse happens when : j changes while i stays fixed.

Because of this Pluto wants iterations differing only in “j”, to execute close together in time, because nearby accesses are likely to stay in cache.

Now consider the schedule agian :

θ(i , j) = c1i + c2j

The coefficient c2 controls how quickly the time changes as “j” changes. If c2 is very large, reused accesses become far apart in schedule time.

For example:

θ(i , j) = i+ 100j

gives:

Even though all these iterations reuse A[0], they execute very far apart in time. That increase the chances that A[0] gets evicted from cache before we get to reuse it.

So Pluto prefers smaller coefficients for dimensions where reuse occurs frequently. This intuition become the cost function (This is a simplified intuition for understanding locality optimization, not Pluto’s exact ILP objective) :

Cost = c1 + c2

Pluto now basically asks ISL to minimize the cost while still satisfying all legality constraints.

6. ISL Solves The Integer Linear Program (ILP)

At this point, Pluto has transformed the scheduling problem into pure mathematics.

It now has:

Constraints (correctness)

c2 ≥ 1

Objective (locality)

min⁡(c1 + c2)

This is a standard Integer Linear Program (ILP) and ISL solves this system mathematically and returns the best legal coefficients.

7. The schedule becomes a loop transformation

Suppose ISL returns :

c1 = 0

c2 = 1

Then the schedule becomes : θ(i , j) = j

This means sort the iterations primarily by j. Which corresponds to loop interchange.

For a different loop with a diagonal dependence, ISL might return c₁=1, c₂=1 giving:

θ(i , j) = i + j

then execution proceeds diagonally, which corresponds to loop skewing.

The important thing to know here is that Pluto never explicitly says :

“Perform interchange.”

“Perform skewing.”

“Perform tiling.”

It only tries to find the schedule coefficients that minimize reuse distance while preserving correctness.

Now Pluto has found the best loop order, but that alone is also not enough for large matrices. Even the best ordering still cause cache misses. So to solve this problem let us deep dive into Tiling.

What Problem Does Tiling Solve

Let us take an example of naive matmul and see why it destroys ours cache

for (i = 0; i < N; i++)
    for (j = 0; j < N; j++)
        for (k = 0; k < N; k++)
            C[i][j] += A[i][k] * B[k][j];

To understand the cache problem we need to know how arrays are stored in memory. They are stored in a row-major order. A 2D array A[row][col] is stored as one long line in memory. First all row 0, then all of row 1, and so on.

The important to understand is, the problem is NOT the multiplication itself, the problem is HOW memory is accessed.

Now now know that the actual memory layout is like this :

[B00 B01 B02 B03 B10 B11 B12 B13 B20 B21 B22 B23]

Suppose we access :

B[0][0]
B[0][1]
B[0][2]
B[0][3]

These are adjacent in memory and CPU cache loves this. The reason behind this is that cache loads memory in chunks called cache lines. Usually 64 bytes at once.

So when CPU loads : B[0][0] it automatically also fetches nearby values for free which are :

B[0][1]
B[0][2]
B[0][3]

This is called Spatial Locality where nearby memory gets reused, which is very efficient.

Now Lets Understand Why Columns Are Terrible

Lets say we access :

B[0][1]
B[1][1]
B[2][1]

Notice one thing here, that we are down a column. But remember our memory layout :

[B00 B01 B02 B03 B10 B11 B12 B13 B20 B21 B22 B23]

If we were look carefully we can find that

B[0][1] -> position 1
B[1][1] -> position 5
B[2][1] -> position 9

these are FAR apart in memory.

Now the reason this is a huge problem is because lets say we have a matrix size :

N = 1024 and each float occupies 4 bytes. Then : B[0][1] to B[1][1] is

1024 x 4 = 4096 bytes apart

But cache line size is only 64 bytes, so that means every access jumps FAR outside the current cache line. So every access needs a new RAM fetch which is going to be extremely slow and inefficient.

Now coming back to our original example of matrix multiplication :

for (i = 0; i < N; i++)
    for (j = 0; j < N; j++)
        for (k = 0; k < N; k++)
            C[i][j] += A[i][k] * B[k][j];

If notice carefully we have B[k][j] inside the innermost loop for(k). So here we are gonna access :

B[0][j]
B[1][j]
B[2][j]

that means walking down a column which we now know is cache-unfriendly.

Now Pluto’s loop interchange definitely helps, it may discover :

for(k)
    for(i)
        for(j)

Now for fixed K :

B[k][0]
B[k][1]
B[k][2]

These are being accessed sequentially, which means walking across rows instead of columns. Which is a HUGE improvement.

But even with perfect order : A, B, and C are still HUGE. Entire matrices cannot fit in cache. So eventually cache eviction still happens. We need to still reload data repeatedly. That is where Tiling comes into play.

The Gap That Tiling Fills

Tiling says “Don’t work on the whole matrix at once.” Instead work on tiny block that fit in cache. For example instead of processing 1024 x 1024 matrix process a 64 x 64 block at a time.

What the tiled loop looks like

The naive loop:

for (i = 0; i < N; i++)
  for (j = 0; j < N; j++)
    for (k = 0; k < N; k++)
      C[i][j] += A[i][k] * B[k][j];

The tiled loop with tile size B:

for (ii = 0; ii < N; ii += B)       // step through row-tiles
  for (jj = 0; jj < N; jj += B)     // step through col-tiles
    for (kk = 0; kk < N; kk += B)   // step through depth-tiles
      for (i = ii; i < ii+B; i++)   // work inside tile
        for (j = jj; j < jj+B; j++)
          for (k = kk; k < kk+B; k++)
            C[i][j] += A[i][k] * B[k][j];

The outer three loops (ii, jj, kk) move between tiles. The inner three loops (i, j, k) work inside one tile. The computation is identical, same multiplications, same additions, same result. But the memory access pattern is completely different.

Lets try to understand this by taking a small example :

1. Take a tiny matrix

Suppose : N = 4 , so matrices are 4x4. We’ll use tile size B = 2. So now the matrix gets divided into 2x2 blocks.

+----+----+
| T1 | T2 |
+----+----+
| T3 | T4 |
+----+----+

Each tile is a small square.

2. What We Do In Normal Multiplication

To compute C[0][0] we load :

A[0][0] A[0][1] A[0][2] A[0][3]

and

B[0][0] B[1][0] B[2][0] B[3][0]

Now later to compute for C[0][1] we AGAIN need many of the same A values. But the cache may have already evicted them. So we reload them which is an inefficiency.

3. What Tiling Does

Instead of computing just C[0][0] we compute :

C[0][0] C[0][1]
C[1][0] C[1][1]

All together. That 2x2 square is one tile.

4. Now Visualize The Reuse

To compute the output tile :

+---------+
| C00 C01 |
| C10 C11 |
+---------+

we load one small tile from A and one from B.

A tile :

A00 A01
A10 A11

B tile :

B00 B01
B10 B11

Once A00 is loaded into cache it gets reused for BOTH C00 and C01. Similarly B00 gets reused for BOTH C00 and C10.

Tiling is one of those concepts that becomes instantly obvious the moment you see it animated, if the memory access pattern isn’t clicking yet, searching for “cache tiling visualization” or “loop blocking animation” on YouTube will make it snap into place in seconds.

As for where tiling comes from in the compiler, it doesn’t get added as a separate step after Pluto. When Pluto is allowed to search over schedules that have a tile-index dimension and an intra-tile dimension for the same loop variable, the ILP it solves naturally lands on a tiled solution. The reason is straightforward: tiling is precisely what minimizes reuse distance when the full matrix doesn’t fit in cache. Pluto doesn’t know the word “tiling” is, it just finds the schedule with the smallest cost, and that schedule, when written out as loop code, is a tiled loop. The math basically forces it there.

Scanning The Polyhedron

Now the question this topic answers is after Pluto runs, the compiler has a transformed polyhedron, a mathematical object described as a system of inequalities.

You can think of these inequalities as describing a geometric region containing all valid loop iterations.

The inequalities can be something like :

0 ≤ ii < N, step B
0 ≤ jj < N, step B  
ii ≤ i < ii+B
jj ≤ j < jj+B
i < N
j < N

This is obviously not code and CPU cannot execute a system of inequalities. Someone has to look at this math object and write out the corresponding for loops with correct bounds. That process of turning a polyhedron back into loop code, is called scanning the polyhedron. That job is done by CLooG or ISL code generator.

How do they work ?

Now the question is:

“How does ISL/CLooG look at inequalities and actually generate nested for loops?”

The answer is simple :

They repeatedly ask: “For this dimension, what are the valid integer values?” That’s literally the entire algorithm.

Lets start with the simplest inequalities

Suppose ISL receives : 0 ≤ i < 4

This describes valid values of : i , So the compiler asks “What values can i take ?”

And the answer is : 0, 1, 2, 3

So code generator emits : for(i = 0; i < 4; i++)

That’s it.

Now Comes Tiling

Suppose the inequalities are :

0 ≤ ii < N

ii ≤ i < ii + B

i < N

Now compiler must generate loops for this particular inequality.

So compiler asks : “What values can ii take?”

Answer : 0 ≤ ii ≤ N with step size B.

So it emits :

for(ii = 0; ii < N; ii += B)

Now the compiler asks : “For this ii, what values can i take?” Compiler sees TWO upper bounds :

Constraint 1 : i < ii + B (tile Boundary)

Constraint 2 : i < N (matrix boundary)

Now to actually satisfy BOTH inequalities, we have to find the actual upper bound. And the answer to that is basically smaller of the two.

Which becomes : i < min(ii + B, N) and

The Lower bound comes from : ii ≤ i

So the generated loop becomes :

for(i = ii; i < min(ii+B, N); i++)

The reason why this min() function is important because the tile wants to continue until ii + B, but the matrix itself ends at N. Most tiles fit perfectly, but the last tile may partially fall outside the matrix.

So the compiler chooses whichever boundary comes first. That is how min() appears, the compiler sees two competing upper-bound constraints and takes the smaller one.

So CLooG/ISL are basically geometric interpreters, they take a look at a geometric region and ask : “What are the legal integer coordinates?” and then they systematically turn those coordinates into nested for loops by :

• picking one dimension

• finding its lower bound

• finding its upper bound

• emitting a loop

• moving inward recursively

This is the complete pipeline, from source code to optimized loops. The compiler builds the iteration domain, finds dependences, computes the best schedule via Pluto, and finally scans the resulting polyhedron to emit runnable code. In the next post we'll see where all of this lives in modern compilers: MLIR.

Conclusion

Polyhedral compilation looks intimidating at first because of all the math, inequalities, schedules, and optimization problems. But underneath all of it, the core idea is surprisingly simple:

A loop nest can be viewed as a geometric space of computations.

Once the compiler converts loops into mathematical objects, transformations that normally feel complicated like loop interchange, skewing, fusion, parallelization, or tiling become mathematical operations on that space.

The compiler is no longer “guessing” optimizations. It is proving which transformations are legal and then searching for schedules that improve locality and parallelism.

That is what makes the polyhedral model so powerful.

Modern systems like Pluto, ISL, and MLIR use these ideas to optimize scientific computing, machine learning kernels, stencil computations, and high-performance code generation. Even though the theory can become very deep, the entire pipeline fundamentally revolves around one question:

“How can we reorder computations without changing the meaning of the program, while making the hardware happier?”

And surprisingly, the answer turns out to be geometry.

I wrote this blog as part of my own journey learning polyhedral compilation and compiler optimizations. My goal here was not to give a fully rigorous research-level treatment, but to build an intuition-first understanding of how the entire pipeline fits together.

If you notice any mistakes, oversimplifications, or inaccuracies, please feel free to point them out. I’d genuinely appreciate corrections and deeper insights from people more experienced in this space.

Here we can clearly see that the value of “x” never changes inside the loop. So x*4 produces the same value for every single iteration. 1,2,3…..all the way to 1,000,000. We are multiplying the same two numbers a million times and then not using 999,999 of the answers.

The CPU doesn’t know this, it just executes the instructions that we give. It has no notion of “I already computed this”.

The fix is obvious once you see it :

Moving the computation of “t” outside of the loop. Same result just 999,999 fewer multiplications. For a million iterations of a tight loop this is a meaningful speedup. That’s what the entire project is about, teaching the compiler to do this transformation automatically.

What does a compiler actually do ? (the IR Layer)

Whenever we write C code, the CPU executes machine code (raw binary instruction). Between these two things, compilers have an intermediate layer called IR short for Intermediate Representation. LLVM’s IR is a textual format that is present in .ll files.

Now the reason IR exist is because transformations like LICM are much easier to do on IR that on C source code (too high-level, too many syntactic complications) or on machine code (too low-level, architecture specific). IR sits at the perfect space which is abstract enough to reason about, concrete enough to optimize.

If you wanna see the IR yourself for the above code run the below command :

Static Single Assignment (SSA)

Before we dive into the complexities its important to understand SSA and what it does.

The rule is simple : every variable is defined exactly once, in exactly one place in the code. New values are represented as new variables.

In normal C code, this is constantly violated :

In SSA form (which is what LLVM IR is), this become :

Every new value gets a new name, and its value are permanently bonded i.e “%x1” will always mean 5 not something else. This concept is gonna be useful in our LICM pass.

Def-Use chain

This is also one of the important concepts that will help us in the future. Lets us understand this with a proper example.

Consider this C code below :

In LLVM IR, this becomes :

Now forget about loops for a second. Just focus on these two instructions and how LLVM remembers them internally.

In LLVM every instruction is a Value object. That means %t is a Value, %res is a Value and %x is a Value. Even the constant 4 is a value.

Now Every single Value object in LLVM holds two things :

This isn’t something that we have to do, LLVM maintains this automatically for us at all times, for every Value in our IR.

The first is its definition, the one instruction that produced it. For “%t” that’s the mul instruction. For “%x” that’s whatever instruction outside the loop created it.

The second is its users list, every instruction that consumes this value as an input. For “%t” that’s the add instruction that uses it. For “%x” that’s the mul instruction.

These two pieces of information together form what’s called the def-use chain. You can traverse it in either direction.

The two directions of traversal

Backward direction : From an instruction, to its inputs, to where those inputs were defined. You call I.operands() to walk this direction. You’re basically asking “where did my inputs come from?”

Forward direction : From a definition, to everything that consumes it. You call I.users() to walk this direction. You’re asking “who depends on my result?”

Our invariance check uses the use-def direction backwards.

Basic Block in IR

IR is not organised as a flat list of instructions. It’s organised into basic blocks. A basic block is actually a sequence of instructions with one strict rule: execution enters at the top and exits at the bottom. There are no branches in the middle.

Every basic block ends with exactly one terminator instruction it could either be a branch (br), a return (ret), or a switch. The terminator says “after this block, go to block X, or go to block Y depending on a condition.”

All the basic blocks are connected through terminators. Basically one block’s terminator points to other blocks as successors. These connections for a graph called Control Flow Graph (CFG).

How do loops look like in CFG ?

A loop in IR is just a cycle in the CFG, a path from some block back to a block you’ve already visited. The specific structure that LLVM recognises is called a natural loop and it has 3 parts (Entry block, Header block, and Body block) :

The header block :

The single entry point of the loop. Every time the loop starts (or restarts after an iteration), execution enters through this one block. This is where the loop condition is typically checked (i < n).

The back edge :

An edge in the CFG that goes from a block inside the loop back to the header. This is what makes it a loop a cycle. At the end of each iteration, execution follows the back edge back to the header to check the condition again.

The body blocks :

These are all the blocks that are “inside” the loop, reachable from the header via the back edge. For a simple loop this might be just one block. For a complex loop with if-statements inside, there could be many.

Visually a simple loop looks like :

Now in LLVM, LoopInfo analysis automatically finds all of these structures. If you want to ask “what loops exist in this function?” It will hand you Loop* objects with methods like L->getHeader(), L->getBlocks(), L->getExitBlocks(), L->contains(BB).

Okay Now we know that the compiler turns this into IR and breaks it into three separate blocks :

Notice that the loop header has two different kind of predecessors arriving to it.

Now the actual problem that our pass needs to solve

We have identified that the computation %t = mul i32 %x, 4 as loop-invariant. So we wanna move it someplace else where it is executed only once. Where ?

Option A : Put it in the entry block. That might work for this simple case, but the entry block could be doing a hundred other things. More importantly, there could be multiple loops in the function, each needing their own hoisted instructions. Dumping everything into entry will definitely create problems in the long run.

Option B : Put it at the top of loop.header. This seems natural. The header is the first thing that runs before the body. But if we look at the diagram again, the header runs on every iteration, not just once. The back edge from loop.body goes back to the header. So if you put the instruction in the header, it still executes a million times.

Option C : Create a new dedicated block that sits between entry and the header. The pre-header is a basically a brand new block that you insert between entry and the header. The thing is the back edge still goes to the header and not to this new block. So the new block only gets executed once, when entry jumps to it at the very beginning.

Now look at this in actual IR

Before our pass :

After our pass :

Couple to things to notice in the updated IR :

• %t = mul i32 %x, 4 is moved from loop.body to loop.preheader. It now runs only once.

• The back edge br label %loop.header at the bottom of loop.body is still unchanged. It still goes to the header and back edge completely skips the preheader which is good since it will not recompute the values.

• %t is still used in loop.body with %res = add i32 %val, %t. This works because the preheader runs before the loop starts, so %t is already defined by the time any iteration uses it. SSA def-use chains remain valid, uses still reference %t, and %t is now defined in the preheader which runs before everything.

Why the two-predecessors problem matters

Here’s the specific thing that makes the pre-header necessary. Look at loop.header in the before case. It has two predecessors. The PHI node at the top of the header exists because of this:

%i = phi i32 [ 0, %entry ], [ %i.next, %loop.body ]

This PHI node says: if I arrived from %entry, then %i = 0. If I arrived from %loop.body, then %i = %i.next. The header has two predecessors, so values that flow into it need a PHI node to merge them.

Now imagine you put your hoisted instruction %t = mul %x, 4 directly in the header, above the PHI nodes. It would again execute every time the header runs: once from entry, and once again every time the back edge fires. Million iterations = million multiplications. Nothing gained.

The preheader solves this by being a block that only entry can reach. No back edge. No PHI node is needed. It executes once, produces %t, and the loop body uses it forever.

Writing the LICM pass

Now that we have an understanding of all the things that are happening conceptually, lets dive to into actually writing the pass.

Implementation-wise, LLVM LICM boils down to 3 phases:

1. Detect loops → using LoopAnalysis

2. Find invariant instructions → isInvariant()

3. Check safety + hoist → move to preheader

Let us start with the “run” function :

This run() function is essentially your control center of the LICM pass. This is the entry point of our pass, and LLVM calls it once for every function and expect it to transform if needed.

The run() function takes in two arguments :

1. Function &F : This is the function our pass is working on.

2. FunctionAnalysisManager &AM : This is how we can access the precomputed analyses. Instead of recomputing things like loops or dominance, you just ask:

• auto &LI = AM.getResult<LoopAnalysis>(F);

• auto &DT = AM.getResult<DominatorTreeAnalysis>(F);

• auto &AA = AM.getResult<AAManager>(F);

LoopAnalysis → LI

• All loops in the function

• Structure of loops

• Blocks inside loops

Without this → you can’t even detect loops

DominatorTreeAnalysis → DT

• Which blocks dominate others

Used for:

• Safety check (does instruction always execute?)

AAManager → AA

• Alias analysis

Used for:

• Memory safety (do two pointers refer to same memory?)

Then we are using a variable called “changed” to know if we have modified the IR or not.

Using LI.getLoopsInPreorder() function we get all the list of loops ordered as [Outer, Inner]. But we need to process the inner loops first so we just reverse the order of iteration using “loops.rbegin()” and “loops.rend()”.

At the end you might see “PreservedAnalyses::none()” and “PreservedAnalyses::all()”. See whenever LLVM computes this like Loop structure, Dominance and Alias info which are expensive computations, so LLVM caches them and resuses them across passes.

So the problme is, when our pass changes the IR, it can break previously computed analyses. So LLVM asks us “Did we change anything that might invalidate analyses?”

Case 1 : We changed the IR so return PreservedAnalyses::none() which means we have modified the program, don’t trust any old analysis.

Case 2 : No changes so return PreservedAnalyses::all() which means we didn’t touch anything, everything is still valid.

Moving on to the “processLoop()” function :

Now this is our core optimization engine which takes a single loop, finds invariant + safe instructions, and moves them to the loop preheader.

The arguments that we are providing to the processLoop() function are :

• Loop *L → the loop to optimize

• DominatorTree &DT → for safety (execution guarantee)

• LoopInfo &LI → needed for CFG updates (preheader creation)

• AAResults &AA → for memory safety

The high level workflow is gonna be something like this :

1. Get/Create preheader

2. Scan loop → find candidates

3. Store candidates

4. Move them outside loop

Firstly we get the preheader for the given loop and if it doesn’t exist then we will create it using :

**preheader = InsertPreheaderForLoop(L, &DT, &LI, nullptr, false);

This transforms our CFG :

Before: entry → loop.header

After: entry → preheader → loop.header

This makes LICM possible, because without this preheader, hoisting has no safe destination.

Then create storage for candidates :

std::vector<Instruction *> toHoist;

We are storing first because never modify the IR while iterating it.

Then Itearate over every block in loop and then over each Instruction. Inside those loops we have to check two things :

1. isInvariant() - Does it depend on loop ?

2. isSafeToHoist() - meaning it has no side effects, no aliasing

If these checks satisfy then push the instruction into the toHoist vector that we created for storage.

Hoisting Phase :

for (Instruction *I : toHoist){
	I->moveBefore(preheader->getTerminator());
}

This basically moves the instructions from the loop body to the preheader.

Lets move on to the isInvariant() and isSafeToHoist() functions

LICM has two filters :

1. Invariant? → Does value change across iterations?

2. Safe? → Will moving it break the program?

If both are true then we hoist.

1. isInvariant() :

Checks whether the instruction produces the same value every iteration or not. An instruction is invariant if all its inputs are defined outside the loop

1. Firstly skip the instruction if it is PHINode since PHI nodes represent changing values.

2. Then Iterate over the operands and check where each operand is defined.

if (auto *defInst = dyn_cast<Instruction>(op))

3. Check if those are inside the loop, and if they are inside the loop return false. Since operands computed inside the loop may change each iteration.

4. If all operands pass then return true.

2. isSafeToHoist() :

This basically makes sure that the instruction does not change program behaviour.

Now this function is just asking us “If I move this instruction out the loop, will the program still behave the same?”

To check this we have 3 conditions that it has to follow :

1. No side effects

2. Memory should be safe

3. It always executes anyway

Side Effect check :

This check basically tells to reject anything that writes to memory, calls functions or changes state.

Memory Safety (alias analysis) :

Lets understand with a simple example first.

Loads read memory:

t = *ptr;

But what if inside loop:

*ptr = i;

Then value of *ptr changes each iteration.

So our code basically iterates over the load and store instruction and checks if they have the same memory location or not.

if (auto *loadInst =dyn_cast<LoadInst>(&I))

Only check loads

Scan entire loop

for (BasicBlock *BB :L->getBlocks()) {
for (Instruction &other : *BB) {

Look at ALL instructions in loop

Find stores

if (auto *storeInst =dyn_cast<StoreInst>(&other))

Check alias

Basically means do these two pointers refer to the same memory?

AliasResultresult =AA.alias(
	loadInst->getPointerOperand(),
	storeInst->getPointerOperand()
);

Dominance Check :

The reason we are checking this is because of one problem, lets understand it using an example :

for (...) {
    if (i % 2 == 0) {
        t = x * 4;
    }
}

Here we can see “t” only runs sometimes and If hoisted :

t = x * 4;
for (...) {
    if (...) { }
}

Now it runs every time which is not good.

So what we are doing is getting all the exit points of an instruction :

SmallVector<BasicBlock *, 4> exitBlocks;
L->getExitBlocks(exitBlocks);

and then checking that instruction must dominate ALL exit blocks, or in other words the instruction must execute on every path through the loop. If not that means its conditional and it cannot be hoisted.

This implementation is intentionally conservative. It avoids unsafe transformations, but it also misses some opportunities that a production compiler like LLVM would handle. Real-world LICM includes more advanced techniques such as:

• Handling chains of dependent invariant instructions

• Speculative execution checks

• More precise memory analysis (like MemorySSA)

That said, the goal here was not to replicate LLVM’s full complexity, but to understand the core idea deeply enough to build it ourselves.

The full implementation is on GitHub - feel free to explore or build on top of it.

I’m still learning LLVM myself, so if you spot anything off or have suggestions, I’d love to hear them. This is as much a learning log as it is a tutorial.

Its a compiler optimization that removes code that does not affect the final output of a program. Any line of code in a codebase that isn’t being used is removed using DCE pass.

For Example :

int main() {

  int x = 10; //dead code

  return 5;
}

Here we can clearly see that the variable “x” doesn’t affect the final output of the program, hence that piece of code will be removed by the compiler.

Note: Not all unused-looking code can be removed. Instructions that have side effects (such as memory writes or function calls) must be preserved.

Why is there a need for this ?

Now we know that CPU executes instructions one by one. Therefore having fewer instructions helps the CPU complete the tasks faster and in less time. Generally, fewer instructions means less work for the CPU. Let’s understand this in more detail :

Example

int main() {
	int x = 10; // unused
	int y = 20; // unused
	return 5;
}

As you can see here we are not using the variables “x” and “y” and since we didn’t remove those lines of code, the compiler will generate instructions for them.

load 10 into register
store into x
load 20 into register
store into y
return 5

While individual load/store operations may seem small in isolation, redundant instructions still increase total execution time and memory traffic.

More instructions = more cycles

Now since we know what and why of DCE let us understand where does DCE actually happen.

High-Level View : What is actually happening and where ?

When we usually write any C++ program, the computer doesn’t understand the C++ code directly. This is where the compiler comes into play.

The compiler works in stages :

Your C++ code
      ↓
Convert to an intermediate form (IR)
      ↓
Optimize the IR (DCE happens here)
      ↓
Convert to machine code

The compiler simplifies your code into a standard internal form called the Intermediate Representation (IR) so it can analyze and optimize it easily.

Now you might get a doubt that why aren’t we directly optimizing the C++ code that we have.

The reason for that it is :

• complex

• ambiguous

• high-level

This could involve operator precedence, function calls, and overloads which would become very hard to optimize reliably.

So now let us try to understand what is LLVM IR and how is it actually helps us optimize.

LLVM IR is like a low-level, simplified version of your program.

Example :

C++:

int main() {
   int x = 5 + 10;
   return 0;
}

LLVM IR:

%1 = add i32 5, 10
ret i32 0

• Here %1 represents a temporary variable

• add i32 5, 10 computes 5 + 10

• ret i32 0 return 0

Here “i32” basically denotes that it is a 32 bit integer.

IR is the perfect place for DCE because of the following reasons:

In IR:

%1 = add i32 5, 10

1. Everything is explicit:

   • Everything is clearly defined

   • no hidden behaviour

2. Data flow is clear :

   You can easily track:

   • where a value is used

   • where it is not

3. Language-Independent

   Same DCE works for:

   • C++

   • Rust

   • Swift

   Because all become LLVM IR

4. Easier than machine code :

   Machine code is:

   • too low-level

   • tied to hardware

   IR is:

perfect balance between abstraction and control

Write your own DCE Pass

Now we have enough back story and we can move on to actually write a proper DCE pass.

Our project setup will look like this :

We start by creating a simple project structure :

DCEPass/
├── test.cpp       ← Input C++ program
├── test.ll        ← LLVM IR (generated)
├── DCEPass.cpp    ← Our custom optimization pass
├── CMakeLists.txt ← Build configuration
└── build/         ← Compiled plugin

1. Writing the Input Program (test.cpp)

Here

• x is never used

• So everything related to x is dead code

2. Converting C++ → LLVM IR

Now we know Computers don’t optimize C++ directly. They optimize an intermediate form called LLVM IR.

We generate IR using:

clang -S -emit-llvm -O0 test.cpp -o test.ll

Type this in the terminal and a “test.ll” file will be generated.

3. Understanding the IR (test.ll)

• alloca → allocate memory (like variables)

• store → assign values

• ret → return

Problem that we are trying to solve:

• %1, %2, and their stores are never used

• This is exactly what DCE should remove

4. Writing the DCE Pass (DCEPass.cpp)

Before we dive into the Pass, we have to understand what a basic block is. A Basic block is a straight-line sequence of instructions with one entry and exit point and no jumps in between.

Now we have to write our core logic which basically removes instructions that :

• have no users

• are not control flow

• have no side effects

Here the function traverses over all the Basic Blocks present in the IR. Inside each basic block it iterates on the instructions. We have to check these instructions and see if they affect our final output or not. If they don’t we simply delete them.

One important thing to note is that we are incrementing the iterator before we delete the instruction to safely perform the check and to not get a segmentation fault.

Some Important functions used here are :

I.use_empty()

No instruction is using this value → safe to delete

This means the result produced by this instruction is never used anywhere else in the program.

I.isTerminator()

Do NOT delete return/branch instructions.

These instructions control the flow of the program, so removing them would break execution.

I.mayHaveSideEffects()

Do NOT delete:
- stores
- function calls

Even if their result is unused, they still affect program state (like modifying memory or printing something.

5. Building the Pass

We use CMake to compile our pass into a plugin:

cmake -S .-B build
cmake --build build

Output:

build/libDCEPass.dylib

6. Running the Pass

We run our pass using LLVM’s opt tool:

opt -S -load-pass-plugin ./build/libDCEPass.dylib \\
-passes="dce-pass" test.ll -o out.ll

This makes an out.ll file which removes the unwanted stores that we saw earlier in the test.ll file

In practice, DCE is often applied repeatedly, because removing one instruction can make other instructions dead.

A quick note : modern compilers like Clang/GCC already do this automatically when you compile with -O1 or higher. You don’t need to write this pass to get DCE in production. The goal here was to understand what’s happening under the hood, stripping away the magic and seeing exactly how the compiler identifies and removes dead instructions at the IR level. Think of it as reading the compiler’s source code, but from scratch.

If you’d like to dive deeper and experiment with the implementation yourself, I’ve uploaded the complete code for this DCE pass on GitHub.

GitHub Repo : https://github.com/Sajid-Zubair/DCEPass