[Bug][VMI] Direct `vbrc(vcmax(..., group=C))` fails bisheng expand

[sundyCoder]

Component

PTO Dialect / ODS (include/PTO/IR)

Description

Summary

对 pto.vmi.vcmax(..., group=C) 得到的 紧凑 group 结果 立刻做
pto.vmi.vbrc(..., size=L, group=C) 展开时，bisheng 编译失败：

Do not know how to expand the result of this operator!

Hypothesis: vcmax(group=C) 的结果仍是未物化的 compact layout；后端在 group broadcast / expand 时无法合法展开该中间形态。

Environment

• Target: a5 / Ascend950
• Backend: vpto
• Observed via PTODSL JIT + msprof sim (sim_dsl)
• Related demo: DynamicBlockMxQuantGatherVfKernel (MX scale: group max → expand)

Minimal repro

mask = pto.vmi.create_mask(128, size=128)
x = pto.vmi.vload(src_ub, 0, size=128)
compact = pto.vmi.vcmax(x, mask, group=8)           # 128 → 8 compact maxima
expanded = pto.vmi.vbrc(compact, size=128, group=8)  # FAIL: direct expand
pto.vmi.vstore(expanded, out_ub, 0, mask)

Semantics expected: each of the 8 group maxima is broadcast across its 16 lanes (back to 128), matching CCE vcgmax + layout expand / BRC.

Actual

Device LLVM / bisheng fails with:

fatal error: error in backend: Do not know how to expand the result of this operator!

(often surfaced as device LLVM compilation failed)

Workarounds (verified PASS)

1. UB materialize then vbrc (recommended today):

compact = pto.vmi.vcmax(x, mask, group=8)
pto.vmi.vstore(compact, tmp_ub, 0, mask8)   # materialize compact layout
compact2 = pto.vmi.vload(tmp_ub, 0, size=8)
expanded = pto.vmi.vbrc(compact2, size=128, group=8)  # OK

2. vselr expand (also PASS): pad compact source, then pto.vmi.vselr with index that repeats each of 0..7 sixteen times.

Clarifications

Path	Result
Direct vbrc(vcmax(...), group=8)	FAIL (this bug)
vcmax → UB store/load → vbrc(group=8)	PASS
Identity / expand pto.vmi.vselr on ui16	PASS (not the failing case)
pto.vmi.vselr ui8 gather (kernel path)	PASS

So this is not a general vselr u16 failure; it is specifically direct group-broadcast expand of vcmax compact results.

Expected fix

vbrc(vcmax_result, size=L, group=C) should lower without requiring an explicit UB roundtrip, or ptoas should insert the materialize barrier automatically when expanding compact group layouts.

Reproduction (minimal)

mask = pto.vmi.create_mask(128, size=128)
x = pto.vmi.vload(src_ub, 0, size=128)
compact = pto.vmi.vcmax(x, mask, group=8)           # 128 → 8 compact maxima
expanded = pto.vmi.vbrc(compact, size=128, group=8)  # FAIL: direct expand
pto.vmi.vstore(expanded, out_ub, 0, mask)

Expected behavior

vbrc(vcmax_result, size=L, group=C) should lower without requiring an explicit UB roundtrip, or ptoas should insert the materialize barrier automatically when expanding compact group layouts.

Actual behavior / error logs

Do not know how to expand the result of this operator!

Git commit

ptoas0.59

Host platform

Linux (x86_64)

Target Ascend arch (if relevant)

a5

PTOAS build level (if relevant)

None

[mouliangyu]

已按 issue 中提供的最小用例，在 PTOAS 0.59、A5 / CANN 9.0.0 环境下通过 PTODSL JIT + msprof op simulator 实际运行，未复现 vbrc(vcmax(..., group=8), group=8) 的 Bisheng 编译报错，kernel 可以正常编译并执行。

请补充能够稳定触发问题的完整 DSL、完整报错日志以及具体 CANN 版本，以便继续定位。