Why VLIW is popular again

VLIW (Very Long Instruction Word) spent most of the last two decades as a specialist's tool. After the commercial struggles of general-purpose VLIW designs, with Intel's Itanium being the canonical example, the architecture retreated into DSPs and embedded media processors, where its constraints were acceptable and its efficiency mattered. For a long stretch, knowing VLIW well was a niche skill.

That has changed. The economics of machine learning have pulled VLIW back into mainstream silicon, and the population of engineers writing compilers and kernels for these machines has grown by roughly an order of magnitude. The reason is straightforward: ML training and inference are dominated by regular, statically analyzable computation, which is precisely the workload VLIW was built to exploit.

The VLIW-versus-out-of-order (OoO) debate is an old one, and for general-purpose code it was settled in favor of OoO. But "settled" rested on assumptions about the workload, and those assumptions do not hold for dense linear algebra.

What is VLIW? The anatomy of an instruction bundle

In a scalar processor, instructions are fetched and retired in program order, and the hardware is responsible for discovering what can run concurrently. VLIW inverts that contract: the compiler groups multiple independent operations into a fixed-width bundle (sometimes called a packet), and the hardware issues every slot in the bundle in the same cycle without checking for dependencies between them.

P1: {
  LOAD  v0, [ptr1]      // 1. Both loads fire simultaneously
  LOAD  v1, [ptr2]      // 2. Reads from distinct addresses, no dependency checking
}
P2: {
  VMAC  v2, v0, v1      // 3. Vector math issues alongside pointer arithmetic
  ADD   ptr1, ptr1, 32  // 4. Advance pointer 1
  ADD   ptr2, ptr2, 32  // 5. Advance pointer 2
  SUB   n, n, 1         // 6. Decrement loop trip count
}
P3: {
  JNZ   n, P1           // 7. Branch back to P1 while n != 0
}

Each packet issues in a single cycle. P1 fires both loads together; P2 then issues the multiply-accumulate alongside the two pointer increments and the trip-count decrement, executing four operations in one cycle, because the compiler has proven they are mutually independent.

The advantage is compute density and power efficiency. The hardware spends no area or energy determining whether the VMAC depends on the preceding LOADs; that guarantee is encoded by the compiler in how the bundle was formed. What this saves is precisely the machinery an OoO core spends recovering the same parallelism at runtime.

Why ML brought VLIW back

The VLIW contract, the compiler proves independence and the hardware trusts it, is exactly what a tensor core wants. A matmul is regular, statically analyzable, and its parallelism is known at compile time. There is no branch prediction to do, no speculative execution to recover from, and the power budget goes to ALUs instead of scheduling machinery.

This is why the GPU's approach of pushing scheduling onto the compiler, and why TPUs and NPUs lean VLIW-like: the workload justifies it. For inference engineers, understanding VLIW is understanding the hardware your kernels actually run on.

ML training and inference are dominated by regular, statically analyzable computation, which is precisely the workload VLIW was built to exploit.

Back to the blog