Migrate to ktir-mlir-frontend 233d851: memory_space rename + tools_ktdp move

[fabianlim]

Bumps the mlir-frontend extra's ktir-mlir-frontend pin 973d67e → 233d851 and adapts to two breaking changes in that range.

Needed by torch-spyre/triton#108, which bumps the same submodule. Until this lands, that PR's numerical tests fail — every test_numerical[*] dies in the MLIR parse worker.

1. spyre_memory_space → memory_space (a3d6bd1)

Not a pure rename — the enum changed meaning and the optional parameter was renamed:

old:  #ktdp.spyre_memory_space<HBM>            kind enum {unspecified, LX, HBM}
new:  #ktdp.memory_space<global>               kind enum {global, ct_local}
      #ktdp.memory_space<ct_local, ct_id = 0>  (was `core = 0`)

Memory-space parsing is now centralized in parser_utils.parse_memory_space, which accepts the new spelling and maps it onto the interpreter's existing internal names, so the execution model is unchanged:

global    → HBM
ct_local  → LX   (ct_id → lx_core_id)

Both frontends (regex and MLIR) route through that one helper, so they can't drift apart.

The old spelling is now explicitly rejected rather than silently defaulting to HBM — see test_construct_memory_view_rejects_pre_rename_spelling. Worth a look during review: silently accepting the pre-rename form would have been the more dangerous failure, since it would place data in the wrong memory space rather than erroring.

2. tools_ktdp moved into mlir_ktdp.tools

b4cb211 consolidated tools_ktdp into mlir_ktdp/tools/, and 822079f inlined ir_utils into tools/__init__.py, so from tools_ktdp.ir_utils import ... no longer resolves.

That import lives inside the _HAS_MLIR try/except ImportError, so the failure surfaced as the misleading "mlir_ktdp / tools_ktdp not installed" — with mlir_ktdp in fact installed and working. This cost real debugging time on the triton side, so the message is corrected to name only what it actually checks.

Scope

51 files, +422/−223 — mostly mechanical (163 attribute substitutions across examples/ and tests/). The substantive changes are confined to 5 files under ktir_cpu/, plus the CI workflow below:

File
parser_utils.py	new parse_memory_space (+72)
mlir_frontend/parser.py	import fix; route through the helper
dialects/ktdp_ops.py, ir_types.py, ops/memory_ops.py	call sites

pyproject.toml / uv.lock carry the pin bump itself.

Also: CI needed cmake>=4.0

Installing the new frontend pin fails in CI with OSError: [Errno 36] File name too long, and the fix has to live here rather than upstream.

torch-spyre/ktir-mlir-frontend#59 addresses the root cause — MLIR's mlir_generate_type_stubs() joins DEPENDS_TARGETS into a 283-char target name, and CMake 3.x writes that whole name into its file-API reply filename, past NAME_MAX (255). #59 pins cmake>=4.0 in build-system.requires, which truncates the name and relies on the trailing hash.

But this workflow installs with --no-build-isolation, which bypasses build-system.requires entirely, so that pin never applies. The pre-install step supplied only scikit-build-core and nanobind, leaving the build to use the runner's CMake 3.x. Adding cmake>=4.0 / ninja>=1.11 there satisfies it directly.

This is why the pin is 233d851 (the #59 branch head) rather than ed069fb6 — and why it alone was not sufficient.

Testing

1322 passed, 10 skipped, 13 xfailed locally; CI green (1191 passed via the MLIR parser, 131 via the regex parser).

Cross-checked against torch-spyre/triton#108 with this branch installed: the 106 failures there drop to 0 (1146 passed, 47 skipped).

[lasch]

should this rank-0 treatment become legal now. See offline discussion about dealing with rank-0.

[fabianlim]

sorry this was a runway commit. I was experimenting with rank-0 in a diff set of experiments and got contaminated in. thanks for finding it out. i have now removed it. This PR should be restricted to only renames of memory spaces and the removal of tools_ktdp.

[fabianlim]

@lasch ready for another look. I removed that stray rank-0 change, and also I refactored abit more of the code, as I felt the earlier version was introducing unncessary helpers that made it look over-complicated

[nwang-ibm]

LGTM.

[lasch]

/lgtmac