Bump ktir-mlir-frontend past the ktdp.memory_space rename

[fabianlim]

Bumps ktir-mlir-frontend from 973d67e to ed069fb6 (upstream main) and adapts this repo to two breaking changes in that range.

The motivating change is a3d6bd1, which replaces ktdp.spyre_memory_space with ktdp.memory_space. Getting past that rename is the point of this PR; the source restructuring came along the way and is split into its own commit.

Commits

9c3084c5	Submodule → 05e7a0f; adapt to source restructuring (7 files)
58fdedd5	Fix the one remaining include in triton_spyre.cc
85f36260	Submodule → ed069fb6; migrate off ktdp.spyre_memory_space (20 files)

Reviewing commit-by-commit is easier than the squashed diff — the first two are pure include-path moves, the third is the semantic change.

1. Source restructuring (05e7a0f)

KTDP's public headers moved, so every consumer needs its includes rewritten:

Ktdp/KtdpOps.hpp      → ktir/Dialect/KTDP/KTDP.h
Ktdp/KtdpDialect.hpp  → ktir/Dialect/KTDP/KTDPDialect.h
Ktdp/KtdpAttrs.hpp    → ktir/Dialect/KTDP/KTDPAttrs.h
Ktdp/KtdpTypes.hpp    → ktir/Dialect/KTDP/KTDPTypes.h

No CMake change was needed: add_ktir_library still sets EXPORT_NAME KtdpDialect and _install_ktir_library still creates the KTIR::KtdpDialect alias, so existing link lines resolve unchanged.

triton_spyre.cc is a separate commit because it was missed initially — it's a .cc file, and it compiles into libtriton rather than spyre-triton-opt, so a lit-only check can't catch it. Worth remembering for the next bump.

2. spyre_memory_space → memory_space (a3d6bd1)

Not just a rename — the attribute's enum changed meaning:

old:  #ktdp.spyre_memory_space<HBM>     kind enum {unspecified, LX, HBM}
new:  #ktdp.memory_space<global>        kind enum {global, ct_local}

The C++ parameter value became kind, and core became the optional ct_id. HBM maps to global — taken from upstream's own migration of test/Dialect/KTDP/add.mlir rather than inferred, since the two enums don't correspond term-by-term. If that mapping is wrong for a Spyre-specific reason, this is the commit to revisit.

Changes:

• 2 C++ construction sites (LowerDescriptorMemory, LowerScalarLoad)
• 18 .mlir test files, 187 occurrences, all the single form spyre_memory_space<HBM>

Nothing here referenced the deleted KTDPAttrInterfaces.h.

Also in this range

• 3da565b — KtirCheckLegality pass stub
• ed069fb — the spyreop dialect, which unblocks [Discussion] Recognize arith/math patterns and lower them to spyreop intrinsics #107. Nothing in this repo emits those intrinsics yet; this bump just makes them available.

Testing

• spyre-triton-opt builds clean against the Spyre LLVM
• lit: 34/34 passed
• pytest: 1146 passed, 47 skipped, 0 failed

The 3 inter_tile_reduce numerical failures that were present before this PR are also resolved — they were stale bindings, not a code issue.

[fabianlim]

Do not merge yet — two temporary pins to revert first

CI is green, but only because this branch points at two unmerged refs. Both must be repinned before merge, in this order:

1. torch-spyre/ktir-cpu#208 — the matching ktir-cpu migration (memory_space rename + tools_ktdp → mlir_ktdp.tools). Until it lands, ktir-cpu main has the pre-rename code and every test_numerical[*] fails in the MLIR parse worker (106 failures).

Once it merges, revert ec965a6a ("TEMPORARY: point ktir-cpu at the branch..."), which restores:

"ktir-cpu @ git+https://github.com/torch-spyre/ktir-cpu@main",

The original line is kept inline as a comment in setup.py for exactly this. The empty commit 9e9e89c9 on top is just a CI re-trigger and can go with it.

2. torch-spyre/ktir-mlir-frontend#59 — the cmake>=4.0 pin that fixes the bindings build. The submodule currently points at 233d851, that PR's branch head rather than a commit on main. Re-pin to the squashed commit once it merges.

Worth noting for #59: this branch is what surfaced that bug. 05e7a0f added MLIR_PYTHON_STUBGEN_ENABLED = "ON", activating a latent overflow — MLIR's mlir_generate_type_stubs() joins DEPENDS_TARGETS into a 283-char target name, and CMake 3.x writes it into the file-API reply filename, past NAME_MAX. Failed as errno 63 locally on macOS and errno 36 in CI on Linux.

Current CI state

Install KTDP MLIR bindings	✅ (was ENAMETOOLONG)
lit	✅ 34/34
pytest	✅ 1146 passed, 47 skipped

Matches local results exactly, so nothing is being masked by the temporary pins — they only change where the dependencies come from, not what is tested.

[fabianlim]

Update: both PRs green — and the revert list is three pins, not two

CI is now passing on both sides:

	DCO	tests
this PR	✅	✅ lit 34/34 · pytest 1146 passed, 47 skipped
torch-spyre/ktir-cpu#208	✅	✅ 1191 (MLIR parser) + 131 (regex parser)

Correcting my note above: there are three temporary pins to unwind, not two. The third is inside ktir-cpu#208.

After torch-spyre/ktir-mlir-frontend#59 merges:

1. Re-pin the submodule here off 233d851 (that PR's branch head) to the squashed commit on main.
2. Re-pin ktir-cpu#208's pyproject.toml + uv.lock the same way — both currently reference 233d851.

After ktir-cpu#208 merges: revert ec965a6a here ("TEMPORARY: point ktir-cpu at the branch..."), restoring torch-spyre/ktir-cpu@main in setup.py. The original line is kept inline as a comment. The empty CI-retrigger commit on top goes with it.

Why #59 alone did not unblock ktir-cpu

Worth recording, since it is easy to hit again. #59 pins cmake>=4.0 in build-system.requires, which fixes the bindings build here — triton's bindings install runs with build isolation, so the pin applies.

ktir-cpu's CI installs with --no-build-isolation, which bypasses build-system.requires entirely. The pin never applied there, the build fell back to the runner's CMake 3.x, and it kept failing with the same ENAMETOOLONG even after being pinned to 233d851. ktir-cpu#208 therefore also adds cmake>=4.0 to its own pre-install step. That workflow change may be worth revisiting once #59 is on main, but it is harmless either way.

Not included here, deliberately

An earlier revision of ktir-cpu#208 widened two regexes in the MLIR frontend so rank-0 !ktdp.access_tile<index> and memref<ElemT> parse — both currently raise ValueError, and LowerScalarLoad emits both forms for a scalar tt.load. That is a real bug but unrelated to this migration and untested in that PR, so it was dropped. It needs its own issue against ktir-cpu; noting it here so it is not lost.