[coderfeli]

Upgrade FlyDSL from 0.3.4.1 to the stable 0.4.0 release across the build, runtime, editable-install, and Triton CI dependency pins.

Import check_smem_capacity from flydsl.runtime.device to match the 0.4.0 API used by gfx1250 GEMM AOT job collection.

Validation:

• Confirmed 0.4.0 is published on PyPI with Python 3.10–3.14 Linux wheels.
• Verified all four dependency pins, TOML and requirement parsing, Python syntax, and Linux/Windows dependency markers.
• Black and Ruff pass for the changed Python files; git diff --check passes.
• GPU runtime tests were not rerun locally for this update; GitHub CI will validate the stable wheel.

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

• ✅ Pre-checks (submodule verification, code formatting)
• ✅ Aiter op tests (gfx942 + gfx950)
• ✅ Triton tests on MI35X (only when aiter/ops/triton/** or related paths are changed)

Extended tests (opt-in via labels):

Label	Tests
ci:gfx1250-ffm-triton	Run the five-shard gfx1250 FFM Triton test suite
ci:triton-300x	Run an additional Triton test job on MI300X in PRs (added automatically when gfx942 configs change); main branch always runs both MI35X and MI300X
ci:triton-355	Run the full Triton test suite on MI35X, not only the tests the change affects
ci:multi-gpu	Aiter multi-GPU tests on the 8-GPU runner
ci:sglang	SGLang integration tests: DeepSeek-R1-MXFP4 accuracy, Qwen 3.5 accuracy
ci:atom	ATOM benchmark: DeepSeek-R1-0528, GPT-OSS-120B
ci:atom_full	ATOM accuracy suite for PR and main models from ATOM models_accuracy.json
ci:vllm	vLLM benchmark: DeepSeek-V4-Pro, MiniMax-M3-MXFP4
ci:all	All standard extended tests (excludes ci:atom_full)

Only add ci:atom_full for FlyDSL or Triton upgrades.
Add labels via the sidebar or gh pr edit 6424 --add-label <label>

One backend per PR:
A PR changes one kernel backend: [Triton/Gluon] (Triton and Gluon count as one), [HIP], [ASM], [CK], [OPUS] or [FlyDSL]. If the title ends up with two backend tags, split the PR -- as stacked pull requests when one part cannot merge without the other.

PR title tags & labels:
Component tags ([Triton/Gluon], [HIP], [CK], [ASM], ...) are added to the PR title and as PR labels automatically from the changed files and re-synced on every push — change-type tags like [fix]/[Perf], op tags like [MLA], and human labels (ci:*) are left untouched. Add the no-auto-title label to stop the title rewrites; labels stay in sync either way.

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

• ✅ Pre-checks (submodule verification, code formatting)
• ✅ Aiter op tests (gfx942 + gfx950)
• ✅ Triton tests on MI35X (only when aiter/ops/triton/** or related paths are changed)

Extended tests (opt-in via labels):

Label	Tests
ci:gfx1250-ffm-triton	Run the five-shard gfx1250 FFM Triton test suite
ci:triton-300x	Run an additional Triton test job on MI300X in PRs (added automatically when gfx942 configs change); main branch always runs both MI35X and MI300X
ci:triton-355	Run the full Triton test suite on MI35X, not only the tests the change affects
ci:multi-gpu	Aiter multi-GPU tests on the 8-GPU runner
ci:sglang	SGLang integration tests: DeepSeek-R1-MXFP4 accuracy, Qwen 3.5 accuracy
ci:atom	ATOM benchmark: DeepSeek-R1-0528, GPT-OSS-120B
ci:atom_full	ATOM accuracy suite for PR and main models from ATOM models_accuracy.json
ci:vllm	vLLM benchmark: DeepSeek-V4-Pro, MiniMax-M3-MXFP4
ci:all	All standard extended tests (excludes ci:atom_full)

Only add ci:atom_full for FlyDSL or Triton upgrades.
Add labels via the sidebar or gh pr edit 6424 --add-label <label>

One backend per PR:
A PR changes one kernel backend: [Triton/Gluon] (Triton and Gluon count as one), [HIP], [ASM], [CK], [OPUS] or [FlyDSL]. If the title ends up with two backend tags, split the PR -- as stacked pull requests when one part cannot merge without the other.

PR title tags & labels:
Component tags ([Triton/Gluon], [HIP], [CK], [ASM], ...) are added to the PR title and as PR labels automatically from the changed files and re-synced on every push — change-type tags like [fix]/[Perf], op tags like [MLA], and human labels (ci:*) are left untouched. Add the no-auto-title label to stop the title rewrites; labels stay in sync either way.

[zufayu]

@aiter-bot review

[aiter-bot]

aiter-bot — queued behind 1 review(s); expect to start in about 50 min. The box reviews one PR at a time.

[aiter-bot]

ROCm/aiter PR #6424 — [FlyDSL] [CI] [Build] Bump FlyDSL to 0.4.0.dev970

Bumps the FlyDSL dependency from 0.3.4.1 to 0.4.0.dev970 in all four pins, re-points the one import the new version relocated (check_smem_capacity to flydsl.runtime.device in the gfx1250 a16w16 GEMM kernel), and adds a launch-regression test for the dispatch-cache semantics the bump depends on.

Review (advisory): ⚠️ NEEDS WORK
Validation (deterministic): NOT RUN — triage required a run of target op_tests/test_flydsl_tensor_shim.py, but auto-validation is disabled (REVIEW_AUTO_VALIDATE=0) and this box has no python environment with flydsl or torch to run it by hand — environment gap, not a PR defect.
Perf (advisory): NOT RUN — the triaged target op_tests/test_flydsl_tensor_shim.py exposes no benchmark entry point (no --scenario bench, no perftest/@benchmark harness), so the perf stage could not time it as written; the PR claims no perf numbers.

⚠️ [verified] The pin swap at requirements.txt:25 / pyproject.toml:11 / setup.py:17 / .github/requirements/triton-test.txt:11 replaces the compiler and runtime under every FlyDSL kernel, and the upstream change sits in the launch path itself (initial launch preserved with null optional inputs, dispatch-filler regeneration avoided) — yet no base-vs-head timing of any FlyDSL op exists, because the triaged target op_tests/test_flydsl_tensor_shim.py is a launch-semantics test with no benchmark entry point and cannot be timed as written, so any latency effect of the swap on real kernels would ship unmeasured. Author must time one representative FlyDSL op (a16w16 GEMM or paged attention) on both pins, or state that only compile-time behavior changed.
📝 [verified] The repo's own CI guide says "Only add ci:atom_full for FlyDSL or Triton upgrades", but this PR carries ci:all — which the guide defines as excluding ci:atom_full — and no ci:atom_full label, so the ATOM accuracy suite will not run against the bump that recompiles every FlyDSL kernel behind setup.py:17's pin. Reviewer should ask for the ci:atom_full label or confirmation that ATOM accuracy coverage is intentionally deferred.
📝 [verified] The 110-passed evidence in the description was run against the FlyDSL compiler source under review, and the wheel-level AOT validation cited was dev968 — the published dev970 wheel that setup.py:17 will install has no direct test evidence in this PR. Reviewer should ask that aiter CI (which installs the published wheel) be confirmed green on gfx942 and gfx950 before merge.
📝 [verified] setup.py:17 now pins 0.4.0.dev970, but .claude/skills/flydsl-kernel-authoring/SKILL.md and .claude/skills/flydsl-kernel-code-cleanup/SKILL.md still reference "pinned FlyDSL 0.3.4.1" — the behavior claims I checked still hold in 0.4.0.dev970 (s_waitcnt still rejects gfx1250), but the version references are now wrong and will mislead kernel authors. Reviewer should ask for a follow-up doc pass on the two skills.

[zufayu]

Where that review came from — I ran the bot on your PR to show what it does. It is not an automatic hook; nothing reviews your PR unless somebody asks.

Any reviewer on the aiter allowlist can ask for one, on any PR including their own. The trigger is a comment containing the words below — shown quoted here, because quoted lines deliberately do not trigger it:

@aiter-bot review

• Reviews the PR at its current head. Comment again after pushing fixes for a fresh pass; a repeat on the same commit is deduped.
• One review runs at a time on one box, roughly 20 minutes. If work is ahead of you the bot replies with your place in the queue, and if the runner is down it says so rather than leaving you waiting for a review that will never start.
• The card is advisory. It never blocks a merge, 🔴 included — it is there to be argued with.

Feedback on the review itself is welcome; it is how the rules get better.