ICE at -O0 / wrong code at -O1,-O2 with BFP16-emulated MMUL<8,8,8> and shuffle_up_fill

[RobinMelhuish]

ICE at -O0 / wrong code at -O1,-O2 with BFP16-emulated MMUL<8,8,8> and shuffle_up_fill

Summary

When compiling code that uses aie::mmul<8,8,8> with -DAIE_API_EMULATE_BFLOAT16_MMUL_WITH_BFP16, the compiler:

• Crashes at -O0 with assertion failure in AIE2PInstructionSelector::selectG_AIE_LOAD_STORE
• Generates wrong code at -O1 and -O2 — element 0 of each 8-element group in the output is systematically corrupted

The bug is triggered when 9 BFP16-emulated MAC calls use shuffle_up_fill/shuffle_down_fill on activation vectors loaded from 3 different source pointers, with all 9 weight vectors pre-loaded.

Compiler version

clang version 20.0.0 (https://github.com/Xilinx/llvm-aie b169186bd072791e958d65deb239f2ac384c30c2)
Target: aie2p-none-unknown-elf

Minimal reproducer

#define NOCPP
#include <stdint.h>
#include <aie_api/aie.hpp>

using MMUL = aie::mmul<8, 8, 8, bfloat16, bfloat16>;

extern "C" {
void repro(
    bfloat16 *src0, bfloat16 *src1, bfloat16 *src2,
    bfloat16 *wts, bfloat16 *dst,
    int32_t n
) {
    auto zvec = aie::zeros<bfloat16, 64>();

    auto w0 = aie::load_v<64>(wts);
    auto w1 = aie::load_v<64>(wts + 64);
    auto w2 = aie::load_v<64>(wts + 128);
    auto w3 = aie::load_v<64>(wts + 192);
    auto w4 = aie::load_v<64>(wts + 256);
    auto w5 = aie::load_v<64>(wts + 320);
    auto w6 = aie::load_v<64>(wts + 384);
    auto w7 = aie::load_v<64>(wts + 448);
    auto w8 = aie::load_v<64>(wts + 512);

    for (int i = 1; i < n - 1; i++) {
        int off = i * 64;
        MMUL acc;

        auto a = aie::load_v<64>(src0 + off - 64);
        auto b = aie::load_v<64>(src0 + off);
        auto c = aie::load_v<64>(src0 + off + 64);
        acc.mac(aie::shuffle_up_fill(b, a, 8), w0);
        acc.mac(b, w1);
        acc.mac(aie::shuffle_down_fill(b, c, 8), w2);

        a = aie::load_v<64>(src1 + off - 64);
        b = aie::load_v<64>(src1 + off);
        c = aie::load_v<64>(src1 + off + 64);
        acc.mac(aie::shuffle_up_fill(b, a, 8), w3);
        acc.mac(b, w4);
        acc.mac(aie::shuffle_down_fill(b, c, 8), w5);

        a = aie::load_v<64>(src2 + off - 64);
        b = aie::load_v<64>(src2 + off);
        c = aie::load_v<64>(src2 + off + 64);
        acc.mac(aie::shuffle_up_fill(b, a, 8), w6);
        acc.mac(b, w7);
        acc.mac(aie::shuffle_down_fill(b, c, 8), w8);

        aie::store_v(dst + off, acc.template to_vector<bfloat16>());
    }
}
} // extern "C"

clang++ -O0 -DAIE_API_EMULATE_BFLOAT16_MMUL_WITH_BFP16 -std=c++20 \
    --target=aie2p-none-unknown-elf \
    -I $(python3 -c "from aie.utils.config import root_path; print(root_path())")/include \
    -c repro.cc -o repro.o

Crash backtrace (-O0)

clang++: llvm/include/llvm/CodeGen/MachineOperand.h:370:
    llvm::Register llvm::MachineOperand::getReg() const:
    Assertion `isReg() && "This is not a register operand!"' failed.

 #9 (anonymous namespace)::AIE2PInstructionSelector::selectG_AIE_LOAD_STORE(...)
#10 llvm::InstructionSelect::selectMachineFunction(...)
#11 llvm::InstructionSelect::runOnMachineFunction(...)

Wrong code behavior (-O1, -O2)

At -O1 and -O2, the code compiles but produces incorrect results on hardware (Strix Point / XDNA2). Element 0 of each 8-element output group has a systematic positive offset. Elements 1-7 are correct.

With identity weight matrices and uniform input, the error on element 0 is exactly +2.34375 at every output position.

Isolation

Systematic testing narrows the trigger to the combination of high register pressure + shuffles + BFP16 emulated MACs:

Test	MACs	Shuffles	Source ptrs	Pre-loaded weights	Result
1 MAC, no shuffle	1	No	1	1	PASS
9 MACs, no shuffle, same src	9	No	1	9	PASS
3 MACs, shuffles, 1 src	3	Yes	1	3	PASS
6 MACs, shuffles, 2 srcs	6	Yes	2	6	PASS
9 MACs, shuffles, 3 srcs	9	Yes	3	9	ICE at -O0 / wrong code at -O1,-O2

Workaround: Loading weights inside a per-source loop (3 at a time) instead of pre-loading all 9 produces correct results.

The same code pattern with mmul<4,8,8> + BFP16 emulation compiles and runs correctly at all optimization levels.

Attached files

• repro-preprocessed.cpp — preprocessed source (generated by compiler crash handler)
• repro-script.sh — reproduction script (generated by compiler crash handler)

conv3x3_fp16_9shuf_o0-005964.sh

conv3x3_fp16_9shuf_o0-005964.zip

[konstantinschwarz]

hi @RobinMelhuish,

thanks for reporting this issue. Is this part of an mlir-aie test case? Can you share the full context so I can try to reproduce this issue on hardware?

[RobinMelhuish]

Hi @konstantinschwarz, thanks for looking at this. Here's a minimal reproducer.

Setup: Single AIE2P tile (Strix Point / NPU2), bf16 activations and weights, compiled with -DAIE_API_EMULATE_BFLOAT16_MMUL_WITH_BFP16 at -O2.

The bug: MMUL<8,8,8> with BFP16 emulation produces correct output with 1 accumulator, but corrupted output with 2 accumulators. The only difference between the two kernels is the number of accumulators — all other code is identical.

Files:

• kernel_1acc.cc — single accumulator, produces correct output
• kernel_2acc.cc — two accumulators processing adjacent blocks, produces corrupted output
• design.py — IRON design file (single tile, single row of 512×8ch bf16)
• test.cpp — host harness (fills input with 1.0, sets all 9 weight positions to identity, expects output of 9.0)

Build (example for 1-acc):

python3 design.py kernel_1acc.o > aie.mlir
clang++ -O2 -std=c++20 --target=aie2p-none-unknown-elf -DAIE_API_EMULATE_BFLOAT16_MMUL_WITH_BFP16 -c kernel_1acc.cc -o kernel_1acc.o
aiecc.py -v --alloc-scheme=basic-sequential --aie-generate-xclbin --aie-generate-npu-insts --no-compile-host --no-xchesscc --no-xbridge --xclbin-name=final.xclbin --npu-insts-name=insts.bin aie.mlir

Results on Strix Point:

• kernel_1acc: 0 mismatches — PASS
• kernel_2acc: 682 mismatches — FAIL (outputs like 60.25, 11.9375, 43.5 instead of 9.0)

The corruption pattern is systematic — the first element of every other 8-pixel block is most affected. This looks like a register allocation issue triggered by the increased register pressure from the second accumulator.

Bug files.zip

[RobinMelhuish]

@konstantinschwarz Additional finding that may help narrow down the root cause.

We've reproduced the same corruption pattern using native bfp16ebs8 weights (no BFP16 emulation). The bug threshold shifts depending on whether emulation is used:

With BFP16 emulation (-DAIE_API_EMULATE_BFLOAT16_MMUL_WITH_BFP16):

• aie::mmul<8,8,8, bfloat16, bfloat16> with 1 accumulator → PASS
• Same with 2 accumulators → FAIL (wrong output values)

With native bfp16ebs8 weights (no emulation flag):

• aie::mmul<8,8,8, bfloat16, bfp16ebs8> with 1-3 accumulators → PASS
• Same with 4 accumulators → FAIL (wrong output values, same corruption pattern)

The calling convention for native weights:

using MMUL = aie::mmul<8, 8, 8, bfloat16, bfp16ebs8>;
aie::block_vector<bfp16ebs8, 64> wt;
aie::block_vector_input_buffer_stream<bfp16ebs8, 64> wStream(weights);
wStream >> wt;
acc.mac(bf16_activation, aie::op_transpose(wt));

Both paths use the same underlying mac_8x8_8x8T_conf hardware intrinsic. The native path just skips the per-MAC weight conversion, which reduces register pressure — hence the higher threshold (4 acc vs 2 acc) before the bug triggers.

This suggests the issue is in the compiler's register allocation for BFP16 MAC operations at the mac_8x8_8x8T_conf level, not specifically in the emulation conversion code. The corruption appears when the total register pressure (accumulators + activation vectors + weight block vectors + internal temporaries) exceeds some threshold.

Hardware: Strix Point / XDNA2 / NPU2. Compiler: Peano from ironenv (March 2026 nightly). All kernels compile without error — the wrong output is generated silently.

Attached reproducer files:

• kernel_2acc.cc — 2 accumulators, produces correct output (PASS)
• kernel_4acc.cc — 4 accumulators, produces wrong output (FAIL)
• design.py — IRON design (single tile, W=480, 3 input rows, 9 bfp16ebs8 weight matrices)
• test.cpp — host harness (identity weights, all-1.0 input, expects 9.0)

Note: 3 accumulators also passes — we've only attached the 2-acc and 4-acc pair for simplicity since that's the clearest PASS/FAIL boundary.

Build: compile kernel as kernel.o (no emulation flag needed), generate MLIR from design.py, build xclbin with aiecc.py.

bug_report.zip

[konstantinschwarz]

Hi @RobinMelhuish,

thanks for providing the full test cases!

I tried reproducing the passing results (both with/without bfp emulation), but do see mismatches:

./app.exe final.xclbin insts.bin 
  MISMATCH [64] = 0
  MISMATCH [65] = 0
  MISMATCH [66] = 0
  MISMATCH [67] = 0
  MISMATCH [68] = 0
  MISMATCH [69] = 0
  MISMATCH [70] = 0
  MISMATCH [71] = 0
  MISMATCH [72] = 0
  MISMATCH [73] = 0
  MISMATCH [74] = 0
  MISMATCH [75] = 0
  MISMATCH [76] = 0
  MISMATCH [77] = 0
  MISMATCH [78] = 0
  MISMATCH [79] = 0
Mismatches: 3968 / 3968
FAIL

I compiled the case as follows:

clang++ -O2 -std=c++20 --target=aie2p-none-unknown-elf -DAIE_API_EMULATE_BFLOAT16_MMUL_WITH_BFP16 -I <path/to/>ironenv/lib/python3.12/site-packages/mlir_aie/include/ -c kernel_1acc.cc -o kernel_1acc.o

python3 design.py kernel_1acc.o > aie.mlir

aiecc.py -v --alloc-scheme=basic-sequential --aie-generate-xclbin --aie-generate-npu-insts --no-compile-host --no-xchesscc --no-xbridge --xclbin-name=final.xclbin --npu-insts-name=insts.bin aie.mlir

/usr/bin/g++ -std=gnu++23 -o test.cpp.o -c test.cpp

/usr/bin/g++ test.cpp.o -o app.exe -lxrt_coreutil

./app.exe final.xclbin insts.bin

Am I missing anything?

[RobinMelhuish]

Hi @konstantinschwarz, thanks for trying these out!

The all-zeros output (every element = 0) suggests the data pipeline may not have executed rather than a precision issue —
when we see the bug on our side, we get correct values for most elements with specific corrupted patterns, not blanket
zeros.

Here's our exact toolchain:

• Peano (llvm-aie): 20.0.0.2026031301+b169186b (commit b169186)
• mlir-aie: 0.0.1.2026031304+9c1e32d
• aiecc.py: commit 9c1e32d7dd57a48fab1765d130a4238ab6546f9f, LLVM 23.0.0
• XRT (xclbinutil): 2.21.0, commit 5c6def2
• Hardware: Strix Point (Ryzen AI HX 370, XDNA2/NPU2)
• Host: Windows 11, MSVC (Visual Studio 2022), linking xrt_coreutil.lib

Kernel compilation happens in WSL2 using the Peano clang and aiecc.py — same as yours. The difference is we compile and
run the host test (test.cpp) natively on Windows with MSVC rather than g++ on Linux.

I've attached our pre-built artifacts so you can test the host pipeline independently:

• final.xclbin + insts.bin for the 1-accumulator case (PASS on our system)
• final.xclbin + insts.bin for the 2-accumulator case (FAIL on our system — corrupted element 0 of each 8-element group)

If these produce all-zeros on your system too, the issue is likely environmental. If the 1-acc passes and 2-acc shows the
corruption pattern, we're seeing the same thing.

build_kernel_1acc.zip
build_kernel_2acc.zip