toolchain.lock

# toolchain.lock -- the single source of truth for ONE exact AIE toolchain.
# Sourced by scripts/toolchain_up.sh. Change this file = change the toolchain (deliberately).
# mlir-aie is built from a CLEAN atassis/mlir-aie integration-branch commit (never a dirty tree), with the
# our kernels overlaid by sync_kernels.sh. Bump by rebasing that branch onto upstream and re-pinning here.
MLIR_AIE_FORK_COMMIT=6ce38ed57763991ec31f8ff79ca5cb0deac51ea6   # branch integration-stack, 4 commits stacked on e53468bff5b (2026-09-12's pin), landed 2026-09-12/13: (1) 5392e78abf9 fixes two O(N)-per-probe scans in aie-decompose-large-dma-bd (id-uniquing re-walk + verifyStridesWraps's default "see current operation" diagnostic note, which reprints the whole module to format a message a ScopedDiagnosticHandler discards -- 46.55% of pass samples profiled), (2) 43ba5174d54 fixes four more of the same anti-pattern in aie-materialize-runtime-sequences (uniquingCounter re-walk + three uncached ConfigureOp::getReferencedDeviceOp() module-wide device scans), (3) 36d4df7765f adds AIE_TRACE_PROGRESS_EVERY, an opt-in stderr heartbeat for both passes (unset = off, zero perturbation), (4) 6ce38ed5776 fixes a FIFTH instance of the same scan (AIEDecomposeLargeDmaBd's getForSymbol/lookupSymbolIn, O(top-level device symbols) per candidate op) -- found LIVE by profiling (perf record -p <pid>, non-destructive) a real 48-layer Gemma-4-12B batched-prefill build mid-run, where it was ~90% of samples; a mlir::SymbolTable built once now replaces it, same contract as the already-fixed AIESubstituteShimDMAAllocations.cpp. NO CODEGEN CHANGE: all four are host-side compiler-pass complexity fixes plus pure observability; every existing lit test's expected output is byte-identical pre/post (164/166 dialect/AIEX + bd-chains-and-dma-tasks + 10/10 Passes/materialize-runtime-sequences, 2 pre-existing XFAIL unchanged) -- DEVICE GATE SKIPPED on that basis, per the repin policy's "skippable only for a byte-identical carry-drop" (this is not a carry-drop, but the byte-identical-output evidence is the same kind of proof the exemption is for). Measured: the real 28-layer qwen3-0.6b decode build's npu_dma_lowered step (this task's own repro) went 71120ms -> 33187ms (2.14x) under commit (1) alone; synthetic sweeps confirm each of (1)/(2)/(4) individually (materialize: 4.98s -> 0.81s at N=8192, 6.1x, though STILL measurably superlinear past N~16384 -- a further mechanism remains open in that pass specifically, separate from the getForSymbol fix in (4)); the real Gemma-4-12B build itself was killed and restarted under this pin rather than measured to completion under the prior one. Owner-directed re-pin (session request, not autonomous). Worktree wt-mlir-integration-stack holds integration-stack (linked worktree of $WS/mlir-aie). MLIR core, Peano, MLIR_DISTRO_WHEEL and NANOBIND unchanged -- this bump touches only lib/Dialect/AIEX/{IR,Transforms} + one header, nothing those depend on. THIS SHA IS LOCAL-ONLY: integration-stack is not pushed, so toolchain_up.sh resolves it from the shared object store and a FRESH CLONE CANNOT BUILD THIS PIN until it is pushed. Tagged mlir-aie-pin-2026-09-13b (this tip) and backup/integration-stack-pre-repin-20260913b (the prior tip, 36d4df7765f), per the ref-naming rule. Rollback: git checkout toolchain.lock + toolchain_up.sh.
MLIR_DISTRO_WHEEL=mlir-24.0.0.2026080106+56bcc187              # Follows utils/clone-llvm.sh, which pins LLVM_PROJECT_COMMIT=56bcc1871734e6c375a254dec0ec74eb18d04a2e; provisioned at $XDNA_CACHE/mlir-distro/24.0.0.2026080106+56bcc187. NO ROLLBACK TO 23.0.0: the newest mlir-aie commit compatible with that wheel (ab85f6114de^, 2026-08-05) predates #3532, the aie-rt fix that zeroes the PT_LOAD p_memsz-p_filesz gap (merged 2026-08-11), so every 23.0.0 pairing that exists carries that corruption. Its cache dir is gone; the wheel beside it is kept, so re-provisioning is a local repack via fetch_mlir_distro.sh.
PEANO_DIST=llvm_aie-22.0.0.2026090801+3e93bf7b                 # The INSTALL SEED, not a reference: install_peano_local.sh hardlink-copies this dist for its runtimes, headers and full binutils (notably llvm-ar, which build_peano_fast.sh does not produce) and swaps only libLLVM/libclang-cpp into the copy -- so it must match PEANO_FORK_COMMIT's LLVM major. Bumped 22.0.0.2026082702+91977805 -> 22.0.0.2026090801+3e93bf7b: this nightly is built from 3e93bf7b, which is EXACTLY the aie-public base the fork below now sits on, so seed and fork share a base instead of the seed trailing it by 2 commits. LLVM major unchanged (22), so the hardlink-copy still matches. Note mlir-aie's own utils/peano-requirements.txt validated 22.0.0.2026090201+a36c62b9 at this tip -- 6 commits older; we take the exact-base one and the smoke gate is what adjudicates the difference.
PEANO_FORK_COMMIT=65fbcdb1f1d9947a42347246533c953a837bb2ec     # ACTIVE Peano = local build of atassis/llvm-aie `integration-stack` = Xilinx/llvm-aie upstream/aie-public 3e93bf7b5541 + the SAME 5 carries, rebased forward from 83eb50ca440f (+20). ZERO carry-drops: `git cherry upstream/aie-public` reports all 5 still unmerged. The two filed carries were re-verified OPEN at their live headRefOid AND patch-id-compared against the rebased forms -- #1148 adjustSPReg large stack frames (bf6309e28d95) and #1155 range-check the spill immediate offset (4dfdbe5707f2) are byte-equal patches to what the previous pin carried, so this is a base advance and not a carry change. Plus the same 3 unfiled carries (two broadcast-size-gate commits, one cherry-pick of llvm-project #153334), resolved by subject. DEVICE GATE MANDATORY: 37 files under llvm/lib/Target/AIE moved, and the window is codegen, not NFC -- a new AIEOuterLoopPointerOptimizer pass, offset-load preference for pointer chains off a 2D-advanced base, an aie_reassoc_ptradd combiner, epilogue WAR renaming, and [AIE2PS] 1024-bit fp accumulator spilling into the cmh bank. Prev pin 299581a415e0, kept reachable as tag peano-pin-2026-09-01; rollback: install_peano_local.sh --activate $XDNA_CACHE/peano-local/<prev> + git checkout toolchain.lock + toolchain_up.sh.
IRON_FORK_COMMIT=aab8083822521ab13cfafc696fe281680f818b78   # amd/IRON floor, NOT an exact-state pin: the gate is `merge-base --is-ancestor`, so a checkout may carry work ON TOP of this and still pass. That is deliberate -- every IRON worktree here sits on a branch with local commits, and an equality pin would fail all of them. aab8083 is `Update mlir-aie to latest nightly (1.4.2.dev) and reduce IRON/mlir-aie duplication (#150)`, computed as the merge-base of every IRON line in this workspace (upstream/devel, pr/mem-copy-bit-width, qwen3-decode-iron and the lane branches) -- i.e. the newest commit ALL of them share. WHY THIS EXISTS AT ALL, added 2026-09-06: IRON was the one toolchain input with no pin, so `IRON_DIR` resolved to whatever the shared checkout happened to be on -- on this date a PR branch (pr/mem-copy-bit-width, 2 ahead of devel and 11 behind), and NOTHING recorded that. The cost was concrete: a decode baseline of 135.96 ms/token could not be attributed to an IRON state, so two independent lanes measuring 205.6 and 218.4 ms/token could not tell a regression from a different base, and both correctly refused to price anything against it. Note this pins the SOURCE line only; it does not pin which worktree `IRON_DIR` points at, which is still an environment decision. Bump by re-computing the merge-base after a rebase, never by copying a branch tip -- a tip excludes every sibling line.
NANOBIND=2.12.0                                                # the dep that silently broke us at 2.13.0