[FlyDSL] Replace the split-K atomic combine with a workspace + reduce kernel by JohnQinAMD · Pull Request #4622 · ROCm/aiter

JohnQinAMD · 2026-08-07T06:50:01Z

Purpose

What breaks

A FlyDSL split-K GEMM recorded into a CUDA graph can spin forever on replay. The device wedges — it does not return a wrong number and it does not recover. The same design also makes the op non-deterministic run to run, and costs accuracy, because partials are rounded to bf16 before they are accumulated.

Root cause

It is a five-step chain. Each step is forced by the one above it.

1. The splits are combined by a bf16 atomic add straight into C. kernels/splitk_hgemm.py:1059 on main:

llvm.AtomicRMWOp(
    llvm.AtomicBinOp.fadd,        # dtype_ is bf16, packed vec2
    pair_ptr_v,                   # points into C
    pair_v,
    llvm.AtomicOrdering.monotonic,
    syncscope="agent",
)

2. An atomic add needs an initialised target, so the kernel needs a barrier to produce one. Somebody must zero the C tile before anyone adds to it, and everybody else must wait for that. That is the entire purpose of the semaphore/signal pair:

step	code	why it exists
first arriving block zeroes the C tile	`zero_c()`	gives the atomic somewhere to add into
it raises `signal[idx] = 1`		announces the tile is initialised
every other block spin-waits on that signal	`split_k_barrier()`	adding before the zeroing lands would corrupt C
the last block to depart resets the counter to 0		restores the entry state for the next launch

3. That barrier only works if the counter is 0 when a launch begins. Step 1 elects "first arrival" by atomicAdd(...) == 0, and step 4 elects "last departure" by comparing against a fixed arrival count. Both are false if the counter starts anywhere other than 0.

4. The counter is zeroed exactly once — where it is allocated. gemm_kernels.py:700 on main:

@functools.lru_cache(maxsize=128)                    # allocated once per (device, stream)
def _get_split_k_tensors(device, stream):
    semaphore = torch.zeros(...)                     # the only memset, ever
    signal = torch.zeros(...)
    return semaphore, signal

After that, the invariant is maintained solely by the kernel resetting the counter on its way out.

5. Under CUDA graph capture, neither holds. The lru_cache entry was allocated the first time the shape ran — during warmup, before capture began — so the recorded graph contains the kernel launch and no memset. Nothing re-establishes the entry state on replay. A counter left non-zero therefore stays non-zero forever: clearing it was never part of the graph.

For small_m that is fatal, because its reduction is gated on the same state it would have to clean (kernels/small_m_hgemm.py:712-800, condensed — the source is FlyDSL MLIR builder calls):

712  prev = atomicAdd(semaphore[idx], 1)
725  first_arrival = (arrive_idx == 0)   # never true if the counter is dirty
728      zero_c_tile(...)                #   so the tile is never initialised
743      store(signal[idx], 1)           #   and the signal is never raised
753  while cur == 0:                     # every block waits here, forever
767      cur = load(signal[idx])
792  last_departure = (arrive_idx == 2 * SPLIT_K - 1)
799      semaphore[idx] = 0              # never reached, so the counter stays dirty

No first arrival → no signal → the wait never exits → the reset never runs. The only path that could clean up is blocked by the state it would clean.

The generic hgemm family survives a dirty counter because there its counter only elects who does the cleanup, with nothing conditioned on a zero start — it completes, with the counter drifting. That is why the currently dispatched family shows no symptom.

What changed

The counter exists only to make in-place atomic accumulation safe. So rather than protect the counter, this removes the accumulation that needs it.

In the main kernel: atomic add into C → plain store into a private slot.

# before — every split adds into the same C, after waiting for it to be zeroed
llvm.AtomicRMWOp(llvm.AtomicBinOp.fadd, pair_ptr_v, pair_v, ...)

# after — every split writes fp32 into a slot nobody else touches
ws_slot     = ks_idx * BLOCK_K_WARPS + wid_k
ws_row_base = ws_slot * m                       # workspace is [SLOTS, m, N]
row_valid   = m_global < m                      # masked: the reduce reads only real rows
WS_[(ws_row, ws_col)] = val                     # no atomics, no barrier, no zeroing

New: kernels/splitk_reduce.py (145 lines) sums the slots. One launch, no coordination:

acc = WS_.vec_load((row, n_base), VEC)
for s in range_constexpr(1, SLOTS):             # fixed order -> bit-reproducible
    part = WS_.vec_load((row + m_rows * s, n_base), VEC)
    acc = arith.addf(acc, part)                 # summed in fp32, not bf16
if HAS_BIAS:
    acc = arith.addf(acc, extf(bias_vec))       # bias folded once, here
C_.vec_store((row, n_base), truncf(acc), VEC)   # C written exactly once

Ordering between the two launches comes from the stream — inside a graph, from the dependency edge between the two nodes. Nothing is shared between blocks, so there is no coordination state a replay can poison.

On the host: a counter cache → a growable workspace. _get_split_k_tensors and _check_split_k_semaphore_capacity are gone, replaced by _get_split_k_workspace sizing slots * m * n fp32 elements, plus flydsl_splitk_prewarm_capture_workspace() so the buffer can be sized before capture starts — growth inside a captured region is not allowed. This follows aiter/tuned_gemm.py::_opus_prewarm_capture_workspace, which does the same for opus.

Deleted, not kept behind a flag: zero_c(), the signal store, split_k_barrier(), the counter reset, the bf16 atomic accumulate, SPLIT_K_SEMAPHORE_MAX_LEN, and the semaphore/signal kernel ABI arguments. Both kernel files end up smaller than before (splitk_hgemm.py 1121 → 983, small_m_hgemm.py 1412 → 1242).

This is not a new pattern in this repo. csrc/opus_gemm already reduces exactly this way and says so in its ABI header — "no atomic_add, no self-clear, no semaphore". That option is not open to the ASM a16w16 split-K GEMM, which ships as precompiled .co binaries and therefore has to fix its semaphore instead (#4494); the FlyDSL kernels are generated from the Python DSL, so the counter can simply go.

Test plan

Three things need proving, and they use different tools.

1. Correctness, reproducibility and capture safety — `op_tests/test_flydsl_splitk_workspace.py`

New file. Seven (shape, split_k, family) cases, three assertions each:

assertion	what it would catch
`test_workspace_matches_reference`	the reduce sums the wrong slots, or misses one
`test_workspace_is_deterministic`	any residual non-fixed-order accumulation
`test_graph_replay_matches_eager`	anything a captured replay carries between runs

The third one deliberately corrupts the workspace between replays (1e30, NaN, 1e30). Without that it would be worthless: a clean capture-and-replay passes on the atomic combine as well, so it has to seed the adversarial state that the old design could not recover from.

pytest -q op_tests/test_flydsl_splitk_workspace.py

2. Roofline sweep — same file, run directly

@benchmark sweep over 6 shapes x 3 split_k x 5 tilings, filtered to launchable configs. Its TB/s column counts the workspace round trip (2 * slots * m * n * 4 bytes), so the design's real cost appears in the table instead of being hidden:

python3 op_tests/test_flydsl_splitk_workspace.py

3. Before/after A/B — two trees, one script

The legacy combine is deleted, so it cannot be selected with a flag. Instead the same script runs against two checked-out trees, mounted over the installed package:

# extract both trees
git archive origin/main         aiter/ops/flydsl | tar -x -C /tmp/base
git archive HEAD                aiter/ops/flydsl | tar -x -C /tmp/head

# run the identical sweep against each, one GPU, 30 timed iterations after 10 warmup
DP=/usr/local/lib/python3.12/dist-packages/aiter
for T in base head; do
  docker run --rm --ipc=host --shm-size=8g \
    --device=/dev/kfd --device=/dev/dri --group-add=video --group-add=render \
    -e HIP_VISIBLE_DEVICES=0 \
    -v /tmp/$T/aiter/ops/flydsl:$DP/ops/flydsl:ro -v $PWD:/work \
    --entrypoint bash "$IMAGE" -lc "python3 /work/ab_full.py /work/$T.json"
done

ab_full.py walks the same config space, times each config twice — once eager, once as a captured graph replayed 30 times — records max abs error against an fp32 torch reference, and writes JSON. Configs an unsupported tiling rejects are recorded as such and excluded from both sides, so the comparison is over the identical set. 71 configs measured on both trees.

Full environment for all three:

IMAGE='vllm/vllm-openai-rocm:kimi-k3@sha256:5aa7e626ff73672f5ca7aae46754570488c23d33ca1ac90756a1d2d1a3fe099b'
docker run --rm --ipc=host --shm-size=16g \
  --device=/dev/kfd --device=/dev/dri --group-add=video --group-add=render \
  -e HIP_VISIBLE_DEVICES=0 --entrypoint bash "$IMAGE" -lc '
git clone -q https://github.com/ROCm/aiter.git /tmp/aiter && cd /tmp/aiter
git fetch -q origin pull/4622/head && git checkout -q --detach FETCH_HEAD
AITER_USE_SYSTEM_TRITON=1 GPU_ARCHS=gfx950 python3 setup.py develop
pytest -q op_tests/test_flydsl_splitk_workspace.py
python3 op_tests/test_flydsl_splitk_workspace.py
python3 aiter/ops/flydsl/test_flydsl_splitk_hgemm.py
'

Test results

MI355X (gfx950). Ratios below are this PR ÷ main, so < 1.0 is this PR being faster or more accurate.

Suites

what	result
`pytest op_tests/test_flydsl_splitk_workspace.py`	21 passed (7 cases x 3 assertions)
perf sweep	68 rows, `err` 0 on every one
`test_flydsl_splitk_hgemm.py` (pre-existing)	4/4 pass, `max_delta = 0.0000`

That last file's thresholds had been loosened to tolerate the atomic path — max_delta_limit of 32.0 and 8.0 with 1% of elements allowed to be arbitrarily wrong, i.e. 4 bf16 ULP. Tightened here to one ULP at 100% on all four cases, since the workspace path measures exactly 0.

Accuracy — better on 71 of 71 configs, none worse

	max abs error
`main` (bf16 atomic accumulate)	3.4760
this PR (fp32 workspace)	0.9994

0.9994 is half a bf16 ULP at that magnitude — correctly rounded, the floor for a bf16 output. The atomic path cannot reach it because it rounds each partial to bf16 before adding. Its error also varies run to run.

Determinism

Bit-identical across two identical runs on all 71 configs. The atomic path differed in 27-75% of elements on 5 of 7 spot checks.

Performance

	median	mean	best	worst	faster on
graph replay	0.951x	0.911x	0.664x	1.179x	45 / 71
eager	1.116x	1.166x	0.858x	1.426x	6 / 71

Split-K is selected for skinny-M decode shapes, and that is where the win lands:

m	configs	graph median	slower
1	39	0.805x	7 / 39
16	8	1.023x	7 / 8
104	18	1.007x	10 / 18
128	6	0.976x	2 / 6

The remaining regressions are the second launch, not the kernel body. Timed in isolation inside a graph, the reduce node costs 1.0-1.3us regardless of workload — 1.06us to move 640KB, 1.01us to move 57KB. It is launch-bound, and that floor matches the residual almost exactly: m16_n7168_k512_spk2 regresses by 1.55us against a 1.27us reduce. Removing that cost means removing the second launch, which is the design.

Eager pays one extra host dispatch, a roughly constant 2-5us. That is implementation cost, not design cost.

Capture safety

A clean capture-and-replay proves nothing here: it passes on the atomic combine too, because the counter only wedges the kernel once it has been left dirty. So both sides are measured with adversarial state seeded before capture. The object differs, necessarily — after this change there is no counter to seed, so the workspace is seeded instead:

	`main` — counter seeded dirty	this PR — workspace filled with 1e30 / NaN
clean capture, then replay	passes (non-discriminating)	passes
adversarial state, then replay	hangs; child killed at a 120 s timeout	passes, bit-identical to eager

The main row is cited from earlier work on this defect, not produced by this PR's suite: it used a seeded-semaphore test against the unpatched tree, reproduced in the public image pinned above (1 failed in 124.56s, child TimeoutExpired). That test cannot have an "after" column here, because the semaphore it seeds no longer exists.

The this PR row is test_graph_replay_matches_eager, which replays four times and refills the workspace with 1e30, NaN, 1e30 between them. Every replay stays bit-identical to eager, because the combine reads only slots it wrote in the same launch.

A pre-existing bug this removes

Legacy split-K with PERSISTENT_N_TILES > 1 in small_m does not merely lose precision, it produces wrong output. Reproduced on a pristine checkout of main, so it predates this change:

code under test	split_k	max abs err	mismatch
pristine `main`, run 1	4	31.99	1372 / 7168
pristine `main`, run 2	4	40.04	3096 / 7168
pristine `main`	1	0.24	0 / 7168

Two runs of the same binary disagree, and split_k=1 — which never enters the combine — is exact. prepare_split_k_tile / split_k_barrier are re-entered per tile against a counter shared with blocks that are at a different tile in their own sequence, so the "first arrival zeroes / last departure resets" invariants do not hold. Not fixed separately: the redesign removes the code that carries the bug.

Overlap and limits

#4494 fixes the same class of defect on the ASM a16w16 split-K path, which cannot take this approach because it ships as precompiled binaries. The two are independent and touch different files.

small_m is not currently dispatched — iter_small_m_registry_configs is commented out at gemm_kernels.py:24 and aiter/configs/ holds 0 small_m entries. The hang this removes is therefore latent rather than something users hit today. The accuracy, determinism and capture-safety results apply to the dispatched hgemm family immediately.

Tool assistance

Claude Opus 5 (1M context) assisted with the root-cause analysis, the redesign, the measurement harness and drafting this description.

github-actions · 2026-08-07T06:50:24Z

🏷️ 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:triton-300x`	Run an additional Triton test job on MI300X in PRs; main branch always runs both MI35X and MI300X
`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: GPT-OSS-120B, DeepSeek-R1-0528, Kimi-K2.5
`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 4622 --add-label <label>

@benchmark

… kernel The FlyDSL split-K GEMM combined its splits with a bf16 atomic fadd straight into C. That accumulate needs an initialised target, so the kernels carried a handshake to get one: the first-arriving block zeroed the C tile, raised a signal, every other block spin-waited on it, and the last one to depart reset the counter for the next launch. That handshake requires the counter to be zero when a launch starts, and nothing can guarantee that under CUDA graph capture. The counter is zeroed only where it is allocated, which happens outside the captured region, so a recorded graph contains no memset and a dirty counter can never be cleared. The small_m family, whose reduction is gated on a block observing prev == 0, then spins forever: no first arrival, so no signal, so no exit from the wait, so no reset. The one path that could clean up is blocked by the state it would clean. Rather than protect the counter, remove the reason it exists. Each split now writes its fp32 accumulator with plain stores into its own disjoint slot of a [SLOTS, m, N] workspace, and a new reduce kernel sums the slots in fixed order, folds bias, casts and writes C once. Ordering between the two launches comes from the stream -- inside a graph, from the dependency edge between two nodes. Nothing is shared, so there is no coordination state a replay can poison. This mirrors csrc/opus_gemm, which reduces the same way ("no atomic_add, no self-clear, no semaphore"). Measured on MI355X (gfx950) across 71 shape x split_k x tiling configs, against the atomic combine: accuracy better on 71/71; max abs error 3.476 -> 0.999, i.e. bounded by half a bf16 ULP -- correctly rounded. Partials are no longer rounded to bf16 before being accumulated. determinism bit-identical run to run on all configs; the atomic path differed in 27-75% of elements on 5 of 7 spot checks. performance graph replay median 0.951x, mean 0.911x, faster on 45/71. Concentrated where split-K is actually selected: m=1 is 0.805x. Eager is ~1.10x from one extra host dispatch. capture replays match eager bit-for-bit, and still do after the workspace is filled with garbage and NaN. The workspace is unpadded and stores are masked to row < m: the reduce reads only real rows, so writing a grid-aligned M_PAD tile was pure write amplification (32x at m=1 with BLOCK_M=32). The legacy combine is deleted rather than kept behind a flag. There is no measured shape where it wins, and it is outright wrong in one: with PERSISTENT_N_TILES > 1 the small_m combine produces garbage (max abs error ~106, 60-85% of elements, differing between two runs of the same binary) because its per-tile arrival counter is shared with blocks at a different tile in their sequence. That bug predates this change and reproduces on a pristine checkout; the redesign makes it moot. Both kernel files end up smaller than before (-153 and -181 lines). test_flydsl_splitk_hgemm.py's thresholds were loosened to 4 bf16 ULP with 1% of elements allowed to be arbitrarily wrong, to tolerate the atomic path. Tightened to one ULP at 100% on all four cases; all now measure 0.0000. op_tests/test_flydsl_splitk_workspace.py adds correctness, bit-reproducibility and graph-replay-matches-eager coverage, plus a conformant @benchmark sweep. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

This PR replaces FlyDSL split‑K HGEMM’s in-place bf16 atomic accumulation (and its semaphore/signal coordination) with a two-stage approach: each split writes fp32 partials into a per-device fp32 workspace, and a dedicated reduce kernel deterministically sums the slots into C.

Changes:

Main split‑K kernels now write fp32 partials to a [slots, m, n] workspace (no atomics, no cross-block barrier state).
New splitk_reduce kernel reduces workspace slots in fixed fp32 order (optionally folds bias once) and writes C once.
Host launcher replaces semaphore/signal cache with a growable per-device fp32 workspace plus a prewarm helper for CUDA graph capture.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
op_tests/test_flydsl_splitk_workspace.py	Adds correctness/determinism/graph-replay tests and a perf sweep for the new workspace+reduce combine.
aiter/ops/flydsl/test_flydsl_splitk_hgemm.py	Tightens split‑K precision thresholds now that accumulation is fp32 and deterministic.
aiter/ops/flydsl/kernels/splitk_reduce.py	Introduces the new reduce kernel that sums workspace slots and writes `C`.
aiter/ops/flydsl/kernels/splitk_hgemm.py	Replaces split‑K atomic combine path with fp32 workspace stores and updates kernel ABI.
aiter/ops/flydsl/kernels/small_m_hgemm.py	Removes semaphore/signal barrier logic and writes split‑K partials into workspace.
aiter/ops/flydsl/gemm_kernels.py	Implements workspace allocation/growth/graph-capture prewarm; launches main+reduce for split‑K.
aiter/aot/flydsl/gemm.py	Updates AOT compilation inputs for the new kernel ABI (workspace pointer).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Four review comments from the Copilot reviewer on ROCm#4622. 1. AOT precompiled only the main split-K kernel, so every split-K config still JIT-compiled the reduce kernel on first use -- exactly the cost GEMM AOT precompilation exists to remove. Compile the reduce kernel too when split_k > 1. The slot count is part of the layout contract between the main kernel, the reduce kernel and the AOT precompiler, so it moves into `_split_k_workspace_slots` and all three read it from there instead of restating `split_k * (block_k_warps if hgemm else 1)`. 2. `_get_split_k_workspace` tested `is_current_stream_capturing()` on the *current* stream while allocating on the passed-in `stream`. When a caller supplies an explicit launch stream those can disagree, and the guard would then miss a capturing stream and allocate into the graph's private pool -- the one thing it exists to prevent. Run the check and the allocation under the same `torch.cuda.device` + `torch.cuda.stream` context. Only the grow path reaches it, so this stays off the hot path. `flydsl_splitk_prewarm_capture_workspace` had the same split, plus `torch.cuda.Stream()` binds to whichever device is current: prewarming for a non-current device tested, and registered the workspace on, another device's stream. Resolve both under `device`. 3. The comment on SPLIT_K_WORKSPACE_MAX_BYTES claimed the fp32 workspace was kept "well below" 2GiB while the constant was exactly 2**31, and attributed the bound to i32 byte offsets. The real bound is the buffer descriptor: `num_records` is a 32-bit BYTE count (clamped to 0xFFFFFFFF in buffer_ops) and voffset is a 32-bit element offset scaled to bytes, so addressing wraps at 4GiB. The constant is right -- half the wrap point -- and the comment now says so. Same fix to the error message. 4. `Case.overrides` used a mutable `{}` as a NamedTuple default, shared by every instance that omits it. Use MappingProxyType so it is actually immutable rather than suppressed with a noqa; same for the shared SMALL_M dict. Verified on MI355X (gfx950) with the patched tree mounted over the installed package in the image pinned in the PR description: pytest op_tests/test_flydsl_splitk_workspace.py 21 passed test_flydsl_splitk_hgemm.py 4/4, max_delta 0.0000 AOT split_k=2 2 kernels compiled AOT split_k=1 1 kernel compiled Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`flydsl_splitk_prewarm_capture_workspace` was added with no production caller: only the new test used it, while the real path -- `tuned_gemm.flydsl_gemm` -> `flydsl_hgemm` -- never called it. The workspace cannot grow inside a CUDA graph capture, so capturing a shape that had not already run eagerly at that `m` raised RuntimeError instead of degrading. Reproduced: run m=1 eagerly, then capture m=64 with the same config and the capture aborts. Call it from `flydsl_gemm`, the same placement and for the same reason as `_opus_prewarm_capture_workspace` in `gemm()`. Dispatch is the right layer because only the tuner knows the `split_k` that decides the size. Soft-fails like the opus one: a prewarm that cannot run must not break eager callers, and capture re-surfaces the problem as a clear error anyway. Calling it per GEMM required making it cheap when warm. It ended every call with `capture_stream.synchronize()`, which was free when only a test called it once but is a host-side sync per eager split-K GEMM from dispatch. Sync only when the call actually allocated. Resolve `device.index` for the same reason: an index-less `cuda` device missed the cache lookup and would have synced every time. Verified on MI355X (gfx950), patched tree mounted over the installed package: capture of an unwarmed shape, before RuntimeError (the repro above) same shape, after captures; replay bit-identical to eager with the workspace NaN-filled warm path no realloc, so no per-GEMM sync split_k=1 / index-less device no-op / no realloc pytest test_flydsl_splitk_workspace.py 21 passed test_flydsl_splitk_hgemm.py 4/4, max_delta 0.0000 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

JohnQinAMD requested review from a team and a lite review from Copilot August 7, 2026 06:50

Copilot started reviewing on behalf of JohnQinAMD August 7, 2026 06:50 View session

JohnQinAMD force-pushed the flydsl-splitk-workspace-reduce branch from a485f58 to 4a5e2ff Compare August 7, 2026 06:55

Copilot AI reviewed Aug 7, 2026

View reviewed changes

Comment thread op_tests/test_flydsl_splitk_workspace.py Outdated

Comment thread aiter/ops/flydsl/gemm_kernels.py Outdated

Comment thread aiter/ops/flydsl/gemm_kernels.py Outdated

Comment thread aiter/aot/flydsl/gemm.py Outdated

zufayu requested a review from coderfeli August 10, 2026 01:16

JohnQinAMD and others added 2 commits August 13, 2026 17:12

JohnQinAMD mentioned this pull request Aug 21, 2026

[ASM] a16w16 split-K: the entry-zero counter is unsafe under CUDA graph capture; opus-style fp32 partials would remove the class #4920

Open

Navigation Menu

Uh oh!

[FlyDSL] Replace the split-K atomic combine with a workspace + reduce kernel - #4622

[FlyDSL] Replace the split-K atomic combine with a workspace + reduce kernel#4622
JohnQinAMD wants to merge 3 commits into
ROCm:mainfrom
JohnQinAMD:flydsl-splitk-workspace-reduce

JohnQinAMD commented Aug 7, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 7, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

JohnQinAMD commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Purpose

What breaks

Root cause

What changed

Test plan

1. Correctness, reproducibility and capture safety — op_tests/test_flydsl_splitk_workspace.py

2. Roofline sweep — same file, run directly

3. Before/after A/B — two trees, one script

Test results

Suites

Accuracy — better on 71 of 71 configs, none worse

Determinism

Performance

Capture safety

A pre-existing bug this removes

Overlap and limits

Tool assistance

Uh oh!

github-actions Bot commented Aug 7, 2026

🏷️ CI Guide

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

JohnQinAMD commented Aug 7, 2026 •

edited

Loading

1. Correctness, reproducibility and capture safety — `op_tests/test_flydsl_splitk_workspace.py`