docs(repro): fused roundtrip performance request

[learning-chip]

No description provided.

[Zhendong404]

VMI lowering analysis and fix

The repro records ASC/VMI ratios of 0.9475 (small FP32), 0.8064 (large BF16), and 0.8963 (wide BF16), below the 0.98 target.

Important scope correction

#1230 fixes a missing lowering capability and physical-layout correctness. It does not by itself make the current #1209 VMI fixture algorithmically identical to the ASC reference. The fixture still contains an explicit workaround: it widens the whole abs_bits vector to f32 and runs a second f32 vcmax only to materialize scale_out.

ASC instead reuses the already computed BF16 group maxima: vcgmax -> bitcast -> vcvt PART_EVEN -> scale store. Therefore the existing VMI source still has an extra full-vector conversion and grouped reduction, and must be rewritten to consume %amax directly before an end-to-end performance claim can be made.

What #1230 fixes

The direct VMI path required by that rewrite is:

group_slots<8xbf16> -> group_slots<8xf32> -> group_store

A compact group_slots source cannot be widened with only one partition stream: 16->32 partitions source lanes into EVEN/ODD streams (and 8->32 into P0..P3). #1230 restores compact result order before group_store and derives full 256-byte physical carriers, including two 128xbf16 / two 64xf32 carriers for a logical 12-group tail rather than an invalid !pto.vreg<384x...>.

• 2x packed widening: vcvt EVEN + vcvt ODD + vintlv.low.
• 4x packed widening: vcvt P0..P3 + three vintlv.low operations.
• Shared by extf, extsi, and extui; slots=1 is excluded because it is a sparse layout.

Alignment status

• Current docs(repro): fused roundtrip performance request #1209 fixture: not algorithmically or instruction-for-instruction aligned with ASC, because of the separate f32 reduction workaround.
• After rewriting the fixture to widen %amax directly: the group-result conversion/store path has a correct VMI lowering, but it still needs an A5 benchmark to demonstrate parity.

Validation for #1230

• Full local ninja build passed.
• 7 focused VMI lit tests passed, including BF16 8/12-group, 2x/4x integer widening, multi-chunk extf, truncf, existing integer extension matrix, and group-slot reduction.
• git diff --check passed.

Fix PR: #1230.

[Zhendong404]

Current status: BF16 trick, precision, and amax UB path

I rechecked the latest PR head (f9ff08d) and the refreshed local VMI lowering against the ASC reference. There are three separate issues here.

1. BF16 trick is now expressible, but the full path is not yet equivalent

The ASC implementation relies on the BF16 bit representation:

BF16
  -> reinterpret U16
  -> convert U16 -> U32
  -> shift left 16
  -> reinterpret F32

The refreshed VMI fixture spells out the same sequence. The integer widening is lowered to:

VZUNPACK(part=0)
VSHL 16

The scale broadcast also lowers to E2B_B16. This confirms that the missing adjacent integer-widening capability was the BF16 trick issue addressed by #1230.

However, the complete VMI amax path still has additional layout materialization around the group-slot store. Therefore this should be considered a lowering capability fix, not instruction-for-instruction parity with ASC.

2. VMI and ASC precision paths were not originally aligned

The original VMI fixture did not reuse the BF16 group maxima in the same way as ASC. It widened the full abs_bits vector to F32 and performed another F32 vcmax, partly to materialize scale_out.

ASC instead reuses the BF16 group maxima:

vcgmax -> bitcast -> vcvt(PART_EVEN) -> scale store

The refreshed VMI source is now much closer: it explicitly performs the BF16 bit trick on the reduced values. But end-to-end numerical equivalence is not established yet. In particular, BF16 rounding, clamp/scale-inverse computation, and tail behavior still need a numerical comparison against ASC. The simulator results below only validate generated instructions and timing; they do not prove precision equivalence.

3. VMI's amax UB round-trip is the remaining structural/performance issue

The VMI source currently does:

vcmax -> BF16 bit trick -> group_slots<8xF32>
       -> store 8 amax values to UB
       -> load those 8 values back
       -> clamp / scale-inverse

ASC also stores the final amax to UB between phases, but its layout is row-oriented: the scale phase loads a contiguous 64-lane amax vector for the 8 tiles in a row. VMI materializes and reloads each tile's compact 8-slot group result separately. That difference causes the extra VSLDB/VSELR instructions; these are from the amax UB materialization/reload path, not from scale broadcast.

On the small Ascend950PR_9599 simulator case (3 rounds, 9 rows, 8 tiles per row):

                         VMI       ASC
duration                 7.13 us   6.84 us
running                  6.89 us   6.31 us
RVECEX                  81702     55539
RVECLD                  10579      6075
RVECST                  13867      6170

The VMI-specific amax-related overhead includes:

VSLDB       216 calls / 4536 cycles
VSELR       648 calls / 10368 cycles
VZUNPACK    216 calls / 2376 cycles
VSHL        216 calls / 1296 cycles

The VZUNPACK+VSHL cost is the intended BF16 trick implementation. The larger remaining gap is the per-tile UB amax materialization and the resulting extra vector load/store work.

Conclusion / next step

#1230 fixes the missing BF16 widening lowering and the compact group-slot physical-layout correctness. The current VMI fixture is therefore capable of expressing the ASC BF16 trick, but VMI is not yet algorithmically, numerically, or performance-equivalent to ASC.

The next optimization should change the VMI dataflow/layout so that the reduced amax values are consumed in a row-level contiguous layout, avoiding the per-tile group_slots<8xF32> UB round-trip and its VSLDB/VSELR materialization. A dedicated numerical comparison is also required before claiming precision alignment.