Posts

Intel Triton XPU #7791 — Why Every Mask Had to Be Validated Before the Loop Was Mutated

Intel Triton XPU RemoveMasks, Part 3 of 3 — Mutation-free preflight, result-less scf.if regions, unsupported stores, and a walker whose current loop had already been erased The first two articles in this series examined two kinds of failure in Intel Triton’s TritonIntelRemoveMasks pass. Part 1 examined an invalid replacement: Always-false masked load + no `other` operand ↓ null value passed into RAUW ↓ compiler crash Part 2 examined an invalid proof: Mask resembles a canonical boundary expression but its `N`, tile width, or predicate does not match the generated guard ↓ mask can be removed without being implied PR #7791 also fixed a third boundary. Even a correct proof and a correct local rewrite can fail if the transformation changes the IR before it has established that the whole transformation is legal. Loop versioning is not a one-operation edit. The pass creates a new condition, inserts an scf.if , clones the original loop into two branches, removes ma...

Intel Triton XPU #7791 — Why a Boundary-Shaped Mask Was Not Enough to Prove It Removable

Intel Triton XPU RemoveMasks, Part 2 of 3 — Canonical loop bounds, mismatched N and END , dynamic dimensions, and equality predicates that did not imply an all-lanes condition Part 1 examined a crash in Intel Triton’s TritonIntelRemoveMasks pass. The pass proved that a masked load would never access memory. But the load had no explicit other operand. The old rewrite attempted to replace the load result with that absent operand: Always-false mask ↓ `other` does not exist ↓ replace uses with a null Value ↓ compiler crash PR #7791 repaired that path by materializing a typed zero. The same patch also fixed a different and more dangerous class of error. The compiler could remove a mask even though the condition guarding the new fast path did not actually prove that the mask was true. The problem appeared in three forms: A loop upper bound had the expected arithmetic shape, but it used a different `N` or tile width from the mask. The loop upper bound was constant, ...

AMD Is Trying to Turn Kernel Diversity Into One Software Asset

The first broad integration was rolled back, but the direction of the software stack is difficult to ignore The GPU software race is often described as a contest over who can write the fastest kernel. That is only part of the problem. A company may have several teams capable of producing high-performance matrix-multiplication kernels. Some may work through template libraries. Others may use compiler-generated code, handwritten assembly, or model-specific optimization stacks. The existence of those kernels does not automatically create one coherent platform. They still need to be: discovered validated matched to the correct problem given the correct arguments launched through a stable runtime and delivered through a reliable software package Recent public code changes inside AMD’s software ecosystem showed an attempt to connect these layers more directly. The central idea was to allow hipBLASLt’s GEMM selection system to choose kernels created by multiple internal kernel technologi...