[codex] add compilable a3 test3 validshape tpush/tpop sample

[zhangstevenunity]

What changed

• recreate test/samples/TPushTPop/a3/test3/kernel.pto using the same PTO syntax/style as the existing a3/test1 and a3/test2 samples
• keep the requested semantics: pto.tmatmul writes into an ACC tile, pto.set_validshape changes it to (8, 16), and the vector side pops 4x16 tiles
• keep the looped cube->vector handoff structure so the sample stays aligned with the existing TPushTPop/a3/test2 pattern

Why

The first PR carried the intended logic, but the file shape/syntax did not match the current A3 sample style closely enough and failed parsing with the available local ptoas.

Validation

• compiled the updated sample with an existing local WSL ptoas 0.23
• command used:
  • /home/rdp/hw-native-sys/PTOAS/build/tools/ptoas/ptoas --pto-arch=a3 --enable-insert-sync -o /tmp/ptoas-a3-test3/kernel.cpp /mnt/c/Users/rdp/Documents/ptoas/test/samples/TPushTPop/a3/test3/kernel.pto
• confirmed generated C++ contains:
  • SetValidShape(...)
  • Tile<TileType::Vec, float, 4, 16, ...>
  • TPOP<..., Tile<TileType::Vec, float, 4, 16, ...>>

Notes

• rebuilding the current workspace ptoas under build-wsl-pr443 is presently blocked by an unrelated compile error in lib/PTO/IR/PTO.cpp (verifyTileBufSameShapeAndElem missing), so sample validation used an already-built local ptoas binary instead

[gemini-code-assist]

Code Review

This pull request introduces a new test case for matrix multiplication using TPush and TPop operations between cube and vector kernels. Several issues were identified regarding the data flow and logic: the vector kernel's loop count and tile shapes do not align with the data produced by the cube kernel, and the use of tfree_from_aic may lead to data loss. Additionally, there are opportunities to optimize the vector kernel by removing redundant tile allocations and move operations. Finally, the placement of set_validshape within the cube kernel loop may cause unintended side effects on subsequent matrix multiplications due to in-place metadata updates.

[gemini-code-assist]

There is a significant data mismatch and potential logic error in the vector kernel loop:

1. Loop Count Mismatch: The cube kernel pushes 4 tiles of shape 8x16 (total 32 rows). The vector kernel loop only runs 4 times (%c4) and pops 4x16 tiles (total 16 rows). To consume all pushed data, the vector loop should run 8 times (%c8).
2. Shape and Split Mismatch: The cube pushes 8x16 tiles with {split = 0}, while the vector pops 4x16 tiles with {split = 0}. Typically, {split = 0} (no split) requires exact shape matching between the producer and consumer. If splitting is intended, the split attribute should likely be non-zero (e.g., split = 1 for height split) to allow popping sub-tiles from a larger pushed slot.
3. Premature Slot Release: pto.tfree_from_aic is called in every iteration. If one push (8x16) is intended to be consumed by two pops (4x16), calling tfree after the first pop will release the FIFO slot and discard the remaining data.

[gemini-code-assist]

The pto.tmov operation is redundant. %fifo_tile is already a tile buffer in the vec location with the required shape and type. You can pass %fifo_tile directly to pto.tprint and remove this move, as well as the unnecessary %vec_print allocation at line 83.

      pto.tprint ins(%fifo_tile : !pto.tile_buf<loc=vec, dtype=f32, rows=4, cols=16, v_row=4, v_col=16, blayout=row_major, slayout=none_box, fractal=512, pad=0>)

[gemini-code-assist]

The placement of pto.set_validshape inside the loop causes an inconsistency between iterations. %acc_tile is initialized with a 16x16 valid shape (line 42). In the first iteration, pto.tmatmul (line 58) operates on a 16x16 region. However, set_validshape updates the tile handle metadata in-place to 8x16, meaning all subsequent tmatmul calls in the loop will see and potentially respect the restricted 8x16 valid shape. If tmatmul is intended to always compute a full 16x16 result, consider moving set_validshape before the loop or resetting the shape after the push.