Huawei’s AscendNPU IR is positioned as the open compiler foundation beneath the BiSheng compiler, not as another end-user programming language. At HyperAI’s ninth Meet AI Compiler technical salon on August 1, 2026, AscendNPU IR architect Hai Lijuan presented how the MLIR-based stack is intended to connect Triton and other operator ecosystems with Ascend hardware. 37

The practical significance is an attempt to separate front-end programming from the increasingly complex work of scheduling tiles, moving data through on-chip memory, coordinating Cube and Vector computation, and generating device code.

AscendNPU IR’s role in the BiSheng compiler

AscendNPU IR is an MLIR-based intermediate representation for compiling Ascend-oriented operators. Its multi-level design provides both higher-level interfaces that hide instruction and synchronization details and lower-level interfaces for developers who need fine-grained control over memory placement and pipeline behavior. 411

The stack is designed to accept input through several routes. DSLs such as Triton and TileLang can lower into AscendNPU IR, while framework and compiler inputs can connect through Torch IR, Linalg/HFusion IR, or HIVM IR. The higher-level paths can provide automatic fusion, tiling, splitting, and scheduling; HIVM exposes more direct control over Ascend storage levels and compute pipelines. 522

A simplified flow looks like this:

Triton, TileLang, or framework IR
              ↓
       MLIR-based AscendNPU IR
              ↓
       HFusion → HIVM lowering
              ↓
       Ascend device instructions and binary

The repository’s documented compilation flow uses bishengir-compile to turn MLIR into a device-side object that can be registered and executed through the CANN runtime. 6

Why the tile-level abstraction matters

A tile is a manageable block of tensor data and computation. Instead of requiring every front end to encode each data transfer, memory-level decision, synchronization point, and hardware instruction separately, AscendNPU IR gives the compiler a common tile-oriented representation.

That abstraction is deliberately layered. At the higher levels, developers can express tensor operations without specifying every hardware detail. At lower levels, the compiler can expose or infer placement in areas such as GM, UB, L1, and L0, as well as the use of Vector, Cube, and data-movement resources. 522

The result is a compromise between portability and tuning: a Triton or framework front end can target the same compiler foundation, while performance-sensitive code can descend to a more hardware-aware representation when necessary. The official architecture documentation describes this as a set of decoupled abstractions that progressively model Ascend instructions, core-local resources, inter-core resources, and system-on-chip resources. 11

HFusion and HIVM divide the optimization work

HFusion: higher-level fusion and scheduling

HFusion is the relatively hardware-independent layer in the two-layer compiler model. It represents tensor operations at a higher level and performs transformations such as fusion, bufferization, tiling, and scheduling before the compiler commits to detailed hardware instructions. 1122

This is where multiple operations can be combined and a larger computation can be divided into tiles suited to the target execution model. The goal is to preserve useful high-level semantics while preparing the computation for Ascend-specific lowering.

HIVM: hardware-aware lowering

HIVM is the hardware-aware layer. It translates tile expressions into operations that reflect Ascend’s execution units, storage hierarchy, and pipeline behavior. Its responsibilities include:

• mapping matrix operations to Cube cores and vector operations to Vector cores;
• inserting or managing communication and synchronization between those units;
• managing intermediate workspace;
• mapping logical tensors to physical on-chip memory;
• handling Cube-oriented layouts such as fractal matrix representations; and
• applying vectorization, tensorization, pipelining, and instruction-level transformations. 214

This division lets the compiler optimize at two different distances from the hardware. HFusion can reason about broader tensor structure and fusion opportunities, while HIVM can reason about the exact memory and execution resources needed to run the resulting tiles.

What Ascend 950 changes

The HFusion/HIVM split remains, but the hardware-aware side must cover more than the earlier memory-based SIMD path. The Ascend 950-focused material describes support for register-based SIMD and SIMT in addition to the existing execution model. 2

Register-based SIMD

With register-based SIMD, data can be loaded from on-chip memory into registers, processed there, and written back. Register-level fusion can keep intermediate values in registers across operations, reducing repeated loads and stores when the computation allows it. 2

SIMT for less regular work

SIMT provides another way to handle suitable irregular-access or divergent portions of an operator. The described approach separates work that benefits from SIMT from dense, SIMD-friendly work, applies the appropriate transformation to each, and then combines the results into the broader vector computation. 2

Tighter Cube–Vector communication

The presentation also highlighted a change in Cube–Vector interaction. Earlier A2/A3 flows used global memory for some crossings between Cube and Vector computation. On Ascend 950, the described path can move Cube results from L0C to Vector on-chip memory and return Vector results to Cube memory, reducing the distance between the two execution domains. 2

That matters for operators in which matrix-oriented Cube work is followed by vector processing. The compiler still has to prove where tensors live and when transfers are required, especially when Cube and Vector operations appear in different control-flow branches.

Compiler passes that make the model practical

Several named passes illustrate how AscendNPU IR turns the abstraction into executable scheduling and memory decisions.

InsertCVLoadStore

The enhanced InsertCVLoadStore flow analyzes Cube–Vector communication across complex control flow rather than inserting transfers through simple local pattern matching. It establishes memory-location anchors—for example, matrix inputs in L1, matrix outputs in L0C, and vector data in UB—then propagates those constraints through the program and inserts conversions or copies when memory domains conflict. 2

On A2/A3, the described crossings can rely on global-memory load and store operations. Ascend 950 can use the tighter on-chip paths where supported. 2

MultiBuffer

MultiBuffer represents multiple copies of an existing tensor. This supports ping-pong buffering and can help overlap data movement with computation when the memory budget and schedule permit it. 1718

AutoBlockify and DynamicCVPipeline

AutoBlockify and DynamicCVPipeline are among the Ascend-specific passes in the Triton-Ascend compiler stack. Their names reflect two central tasks: dividing computation into executable blocks and constructing Cube–Vector pipeline behavior. 19

The documented feature set also includes automatic memory planning, synchronization, scheduling, and Cube–Vector optimizations. 24

CV 1:2 splitting

The presentation described a one-Cube-to-two-Vector-core relationship for a relevant Ascend configuration. AutoSubTiling can divide Vector work so that the two Vector cores process separate portions concurrently. 214

What the open-source release means for developers

Huawei open-sourced AscendNPU IR alongside Triton-Ascend for community co-development. Triton-Ascend is the Ascend-oriented Triton compilation framework, retaining core Triton syntax while adding Ascend-specific compilation and deployment support for A2, A3, and 950-series products. 3037

The release also creates a more direct path for developers who want to work on compiler passes, front-end integration, operator lowering, or hardware-aware optimization without building an entire compiler stack themselves. The reported community program includes repository-linked internships and task-based rewards, with developers claiming listed tasks and submitting completed work under the program’s rules. 31

Developers without local Ascend hardware can reportedly use HiDevLab, the Ascend community’s cloud environment, with 100 free compute hours. The available reporting confirms the allowance but does not specify all eligibility, verification, expiry, or regional-availability conditions, so those terms should be checked when registering. 31

The larger takeaway

AscendNPU IR’s main proposition is architectural: make Ascend hardware accessible through common compiler entry points while preserving a route to detailed hardware tuning. Triton, TileLang, and framework IR can enter at higher abstraction levels; HFusion can perform broader transformations; HIVM can lower tiles into the memory, core, communication, and pipeline decisions required by Ascend devices. 511

Ascend 950 raises the optimization ceiling by adding register-based SIMD, SIMT, and tighter Cube–Vector data paths. Whether that translates into better real-world performance still depends on operator shape, memory pressure, control flow, compiler maturity, and the target chip. The open-source stack makes those trade-offs more inspectable—and gives compiler and operator developers a way to participate in improving them.

Huawei’s AscendNPU IR is positioned as the open compiler foundation beneath the BiSheng compiler, not as another end-user programming language. At HyperAI’s ninth Meet AI Compiler technical salon on August 1, 2026, AscendNPU IR architect Hai Lijuan presented how the MLIR-based stack is intended to connect Triton and other operator ecosystems with Ascend hardware. 37

The practical significance is an attempt to separate front-end programming from the increasingly complex work of scheduling tiles, moving data through on-chip memory, coordinating Cube and Vector computation, and generating device code.

AscendNPU IR’s role in the BiSheng compiler

AscendNPU IR is an MLIR-based intermediate representation for compiling Ascend-oriented operators. Its multi-level design provides both higher-level interfaces that hide instruction and synchronization details and lower-level interfaces for developers who need fine-grained control over memory placement and pipeline behavior. 411

The stack is designed to accept input through several routes. DSLs such as Triton and TileLang can lower into AscendNPU IR, while framework and compiler inputs can connect through Torch IR, Linalg/HFusion IR, or HIVM IR. The higher-level paths can provide automatic fusion, tiling, splitting, and scheduling; HIVM exposes more direct control over Ascend storage levels and compute pipelines. 522

A simplified flow looks like this:

Triton, TileLang, or framework IR
              ↓
       MLIR-based AscendNPU IR
              ↓
       HFusion → HIVM lowering
              ↓
       Ascend device instructions and binary

The repository’s documented compilation flow uses bishengir-compile to turn MLIR into a device-side object that can be registered and executed through the CANN runtime. 6

Why the tile-level abstraction matters

A tile is a manageable block of tensor data and computation. Instead of requiring every front end to encode each data transfer, memory-level decision, synchronization point, and hardware instruction separately, AscendNPU IR gives the compiler a common tile-oriented representation.

That abstraction is deliberately layered. At the higher levels, developers can express tensor operations without specifying every hardware detail. At lower levels, the compiler can expose or infer placement in areas such as GM, UB, L1, and L0, as well as the use of Vector, Cube, and data-movement resources. 522

The result is a compromise between portability and tuning: a Triton or framework front end can target the same compiler foundation, while performance-sensitive code can descend to a more hardware-aware representation when necessary. The official architecture documentation describes this as a set of decoupled abstractions that progressively model Ascend instructions, core-local resources, inter-core resources, and system-on-chip resources. 11

HFusion and HIVM divide the optimization work

HFusion: higher-level fusion and scheduling

HFusion is the relatively hardware-independent layer in the two-layer compiler model. It represents tensor operations at a higher level and performs transformations such as fusion, bufferization, tiling, and scheduling before the compiler commits to detailed hardware instructions. 1122

This is where multiple operations can be combined and a larger computation can be divided into tiles suited to the target execution model. The goal is to preserve useful high-level semantics while preparing the computation for Ascend-specific lowering.

HIVM: hardware-aware lowering

HIVM is the hardware-aware layer. It translates tile expressions into operations that reflect Ascend’s execution units, storage hierarchy, and pipeline behavior. Its responsibilities include:

• mapping matrix operations to Cube cores and vector operations to Vector cores;
• inserting or managing communication and synchronization between those units;
• managing intermediate workspace;
• mapping logical tensors to physical on-chip memory;
• handling Cube-oriented layouts such as fractal matrix representations; and
• applying vectorization, tensorization, pipelining, and instruction-level transformations. 214

This division lets the compiler optimize at two different distances from the hardware. HFusion can reason about broader tensor structure and fusion opportunities, while HIVM can reason about the exact memory and execution resources needed to run the resulting tiles.

What Ascend 950 changes

The HFusion/HIVM split remains, but the hardware-aware side must cover more than the earlier memory-based SIMD path. The Ascend 950-focused material describes support for register-based SIMD and SIMT in addition to the existing execution model. 2

Register-based SIMD

With register-based SIMD, data can be loaded from on-chip memory into registers, processed there, and written back. Register-level fusion can keep intermediate values in registers across operations, reducing repeated loads and stores when the computation allows it. 2

SIMT for less regular work

SIMT provides another way to handle suitable irregular-access or divergent portions of an operator. The described approach separates work that benefits from SIMT from dense, SIMD-friendly work, applies the appropriate transformation to each, and then combines the results into the broader vector computation. 2

Tighter Cube–Vector communication

The presentation also highlighted a change in Cube–Vector interaction. Earlier A2/A3 flows used global memory for some crossings between Cube and Vector computation. On Ascend 950, the described path can move Cube results from L0C to Vector on-chip memory and return Vector results to Cube memory, reducing the distance between the two execution domains. 2

That matters for operators in which matrix-oriented Cube work is followed by vector processing. The compiler still has to prove where tensors live and when transfers are required, especially when Cube and Vector operations appear in different control-flow branches.

Compiler passes that make the model practical

Several named passes illustrate how AscendNPU IR turns the abstraction into executable scheduling and memory decisions.

InsertCVLoadStore

The enhanced InsertCVLoadStore flow analyzes Cube–Vector communication across complex control flow rather than inserting transfers through simple local pattern matching. It establishes memory-location anchors—for example, matrix inputs in L1, matrix outputs in L0C, and vector data in UB—then propagates those constraints through the program and inserts conversions or copies when memory domains conflict. 2

On A2/A3, the described crossings can rely on global-memory load and store operations. Ascend 950 can use the tighter on-chip paths where supported. 2

MultiBuffer

MultiBuffer represents multiple copies of an existing tensor. This supports ping-pong buffering and can help overlap data movement with computation when the memory budget and schedule permit it. 1718

AutoBlockify and DynamicCVPipeline

AutoBlockify and DynamicCVPipeline are among the Ascend-specific passes in the Triton-Ascend compiler stack. Their names reflect two central tasks: dividing computation into executable blocks and constructing Cube–Vector pipeline behavior. 19

The documented feature set also includes automatic memory planning, synchronization, scheduling, and Cube–Vector optimizations. 24

CV 1:2 splitting

The presentation described a one-Cube-to-two-Vector-core relationship for a relevant Ascend configuration. AutoSubTiling can divide Vector work so that the two Vector cores process separate portions concurrently. 214

What the open-source release means for developers

Huawei open-sourced AscendNPU IR alongside Triton-Ascend for community co-development. Triton-Ascend is the Ascend-oriented Triton compilation framework, retaining core Triton syntax while adding Ascend-specific compilation and deployment support for A2, A3, and 950-series products. 3037

The release also creates a more direct path for developers who want to work on compiler passes, front-end integration, operator lowering, or hardware-aware optimization without building an entire compiler stack themselves. The reported community program includes repository-linked internships and task-based rewards, with developers claiming listed tasks and submitting completed work under the program’s rules. 31

Developers without local Ascend hardware can reportedly use HiDevLab, the Ascend community’s cloud environment, with 100 free compute hours. The available reporting confirms the allowance but does not specify all eligibility, verification, expiry, or regional-availability conditions, so those terms should be checked when registering. 31

The larger takeaway

AscendNPU IR’s main proposition is architectural: make Ascend hardware accessible through common compiler entry points while preserving a route to detailed hardware tuning. Triton, TileLang, and framework IR can enter at higher abstraction levels; HFusion can perform broader transformations; HIVM can lower tiles into the memory, core, communication, and pipeline decisions required by Ascend devices. 511

Ascend 950 raises the optimization ceiling by adding register-based SIMD, SIMT, and tighter Cube–Vector data paths. Whether that translates into better real-world performance still depends on operator shape, memory pressure, control flow, compiler maturity, and the target chip. The open-source stack makes those trade-offs more inspectable—and gives compiler and operator developers a way to participate in improving them.