VMI/MI 2-stage double buffer compilation error vs ref CCE

[learning-chip]

• Reproducer for feature gap 05 in missing VMI features for high-perf simd kernels #997
• CCE stages=2 ping-pong builds; VMI stages=2 desired path hits layout reject; target MI crashes bisheng.
• stages=1 chunked path still lowers.
• On-device / msopprof BW check left as TODO. added on-device verification in recent commits

See docs/repro/pipelining/README.md to reproduce.

Tracking issue: #1023

[mouliangyu]

The current failure does not appear to isolate a multi-stage ping-pong issue.

Both the stages=1 block_k=512 case and the stages=2 block_k=1024 case fail first in the wide VMI vector body, at the same layout relation around bf16 -> f32 -> vmul. At present, 512 x T-style wide VMI tiles are not a supported codegen target. This is an intentional boundary: allowing such a large logical tile to remain live across the VF body makes register pressure and spilling much easier to trigger, so current lowering expects the computation to be expressed with smaller supported vector tiles/chunks.

Therefore, the compilation error in this reproducer should not currently be attributed to ping-pong buffer handling. The stages=2 case is extending an already unsupported 512-wide VF formulation to 1024 lanes.

To isolate the pipeline question, could we keep the VF body at a supported width (for example, process the block with 128/256-lane chunks) and change only the outer schedule:

stages=1: one UB slot + MTE2 -> V -> MTE3
stages=2: two UB slots + the same chunked VF body + ping-pong events

The reproducer should include the actual MTE2/MTE3 operations and slot-reuse synchronization. If stages=1 compiles and the otherwise identical stages=2 form fails or loses overlap, that would demonstrate a pipeline/buffer-lifetime issue independently of unsupported 512 x T VMI codegen.

If direct 512 x T VMI support is required, it should be discussed as a separate feature request together with the intended register-pressure/spill strategy.