[PTO v0.58] Publish reproducible Shared TLOAD API validation and toolchain pin

[zhoubot]

Summary

The Shared TLOAD API work exists on temp/shared-tload-integration-20260811 at a1f085ea1d3ffd87560f213bedd9038e57b54917, but there is no check run attached to that commit and the consuming build repository currently follows the unrelated moving linx branch (aa3b165057dcd041e7f0bf1a7d0fd2ccff7521b2).

As a result, downstream users cannot obtain a reproducible, attested TileOP API + LLVM pairing for the new GM-to-Shared/output-form TLOAD interface.

Expected LLVM pairing:

LinxISA/llvm-project
temp/shared-tload-integration-20260811
eb64de8afcbda043aec7e56dae346905dc982039

Suggested acceptance criteria

• Add CI on the Shared TLOAD branch that runs the API compile suite, including test/tileop_api/src/SharedTLoad.cpp, with the exact compatible LLVM revision.
• Verify generated assembly/object code uses 32-bit B.IOS and the current B.IOR operand order; reject retired C.B.IOS output.
• Publish the compatible LLVM SHA in a machine-readable manifest or lock file.
• Promote the validated API commit to a stable consumable ref, or document that downstream build manifests must pin a1f085e... directly.
• Add a downstream smoke contract for SuperNPUBench matmul_shared so the API test cannot pass independently of its primary workload consumer.

[zhoubot]

Cross-repository dependencies:\n\n- Toolchain component locking and tuple reconstruction: https://github.com/LinxISA/linx-toolchain-build/issues/4\n- Downstream matmul_shared compile/run coverage: PTO-ISA/SuperNPUBench#46

[zhoubot]

2026-08-14 dependency update: the current consumable linx@6a4378428e4f69c23923cec4a99c759a968b724b still cannot be promoted as validated evidence because make check passes only 6/15 checks. The failure set mixes stale PTO/LLVM projection assertions with real active API emission drift.

Detailed reproducer and split acceptance criteria are tracked in #9:
#9

This issue's publication/pin criteria should require #9 green at the exact PTO-SPEC/LLVM/API tuple, rather than treating branch availability alone as validation.

[zhoubot]

2026-08-31 PTO 0.58.5 identity gap

The publication/pin requirement remains open:

PTO-SPEC main@0d336526 architecture_version = 0.58.5
TileOP API linx@9550309 VERSION = 0.58.3
LLVM used by toolchain build = adcb8794

The current adcb8794 compiler does not emit the .note.pto.isa identity implemented on the separate LLVM topic codex/pto-v0585-sync@fe1a663d. The toolchain build still follows moving dev-llvm15_56 and linx branches, so a green package build does not attest a PTO 0.58.5 compiler/API tuple.

PR #41 fixes TSEL lowering and restores the API gate, but intentionally does not change the API release identity:
#41

Remaining closure is still:

1. publish an API contract explicitly tied to the PTO 0.58.5 projection;
2. consume an LLVM build that emits the matching identity note;
3. record exact LLVM/API/PTO SHAs in the toolchain package;
4. rebuild and execute representative SuperNPUBench workloads with that tuple.