Skip to content

test(rocke): add a per-flavor skip-list to the IR validity gate - #14211

Closed
CongMa13 wants to merge 2 commits into
developfrom
users/congma13/rocke/ir-validity-skip-list
Closed

CongMa13 wants to merge 2 commits into
developfrom
users/congma13/rocke/ir-validity-skip-list

Conversation

@CongMa13

Copy link
Copy Markdown
Contributor

ISSUE ID : AICK-2694


Summary — For human reviewers

The short version

check_ir_validity.py --strict fails on every host whose clang is older than the newest wired arch.
That clang cannot measure some gfx1250 cases.
The tool reports them as UNVALIDATED, and --strict treats any UNVALIDATED case as a failure.
This PR adds a per-flavor skip-list.
A case on the list may stay UNVALIDATED.
Any other UNVALIDATED case still fails.

This PR is one step toward running the gate in CI.
It changes only the tool and its tests.
It does not add the CI entry.

Why this has to be a list and not a count

A simple floor on the validated count also lets old toolchains pass.
But a floor hides which cases went unmeasured.
A new case that stops validating could stay under the floor without notice.
The list names each expected case and gives a reason.
A new UNVALIDATED case fails the run.
A listed case that starts to validate also fails the run.
This forces the entry out of the list in the change that fixes it.
The list only shrinks, like KNOWN_BAD.

How it works

  • SKIP_UNVALIDATED maps each flavor to its expected UNVALIDATED cases, with a reason.
    • llvm20: 8 cases. Four need llvm23 to lower. Four target gfx1250, which this clang cannot target.
    • llvm22: 4 cases. All four need llvm23 to lower.
    • llvm23: no cases.
  • A flavor with no entry expects no UNVALIDATED case.
  • Runs without --strict behave as before.
  • The stale check runs only under --strict.
    A developer host with a newer clang of the same flavor does not fail the default gate.

How this was tested

I ran check_ir_validity.py --strict in four toolchain images on the rebased tree (246 cases).

Toolchain Flavor Result
ROCm 7.1.1 llvm20 GREEN, 8 skip-listed
ROCm 7.2.0 llvm22 GREEN, 4 skip-listed
One llvm23 build llvm23 GREEN, all 246 validate
A second llvm23 build llvm23 RED, 7 failures (see below)

I also forced two failures.
An empty llvm22 list fails and names the four cases.
A listed llvm23 case that validates fails as stale.
Each run takes about 12 seconds.

One finding outside this PR

On the second llvm23 build, seven gfx950 fp16 attention cases fail to compile.
The error is Operand has incorrect register class.
The first llvm23 build compiles all 246 cases.
This PR does not touch emission.
The failure depends on the compiler build and exists without this PR.
Check which llvm23 build the CI image carries before the gate runs in CI.

Reviewing this

One commit.
Two files: the tool (+70 −6) and its test file (+55).
No emitter file changes.


Summary — For AI reviewers

Change surface

rocke/platform/tools/check_ir_validity.py             +70 -6
rocke/platform/tests/core/test_arch_domain_artifact.py +55

No file under core/, helpers/, instances/, cpp/ or library/ changes.
The change cannot alter emitted IR.

The gap being closed

Situation under --strict Before After
UNVALIDATED, listed for the flavor fail pass
UNVALIDATED, not listed fail fail
Listed, now validates not checked fail (stale)
Missing toolchain or wrong flavor fail fail (unchanged)

Properties to verify

  1. An unlisted UNVALIDATED case fails under --strict.
    _skip_list_verdict returns it in unexpected.
    main() prints RED and returns 1 before the GREEN line.
  2. A listed case that returns OK fails under --strict.
    _skip_list_verdict returns it in stale.
    Confirm that a listed case outside the selection (--only) is not stale.
  3. --strict is required for both new failures.
    Confirm that a run without --strict returns the same exit code as before.
  4. KNOWN_BAD handling is unchanged.
    new_bad and stale return before the new checks.
  5. Every list entry names a real corpus case.
    test_every_entry_names_a_corpus_case_and_a_reason checks this.
  6. A flavor missing from the table gets an empty list.
    SKIP_UNVALIDATED.get(flavor, {}) returns an empty dict.

Repo rules that apply

  • No emitter file is touched. Confirm that remains true.
  • Relative paths only: the diff adds no absolute path.
  • Python only, no shell helper.
  • Device identifiers only: the diff names gfx1250, no product name.

Known weak points

  • The table holds exact case IDs. A corpus rename needs a table edit. The test in property 5 catches a dangling ID.
  • The table covers llvm20, llvm22 and llvm23 only. A new flavor needs a new entry.
  • The reasons are free text. Nothing checks that a reason matches the actual cause.

Scope calibration

A finding that this PR does not add the CI entry, the ctest registration or the installed artifact is out of scope.
Those are the next changes.
A finding that this PR does not fix the seven llvm23 failures is also out of scope.

What review cannot establish from the diff

  • Whether the CI clang is the build that passes or the build that fails.
  • Runtime on a CI runner. The measured 12 seconds come from a 2-CPU host.
  • Behavior on Windows. No Windows host ran the tool.

Test plan

  • check_ir_validity.py --strict GREEN on llvm20 (ROCm 7.1.1)
  • check_ir_validity.py --strict GREEN on llvm22 (ROCm 7.2.0)
  • check_ir_validity.py --strict GREEN on one llvm23 build
  • Forced unexpected case fails; forced stale entry fails
  • ValiditySkipListTest and ValidityGateTest pass
  • pre-commit run --from-ref origin/develop --to-ref HEAD passes
  • Second llvm23 build: 7 failures, independent of this PR (deferred)
  • Windows run (deferred)
  • CI entry and ctest registration (next change)

🤖 Generated with Claude Code

@CongMa13
CongMa13 requested a review from a team as a code owner October 22, 2026 18:06
@therock-pr-bot

therock-pr-bot Bot commented Oct 22, 2026 •

Copy link
Copy Markdown

✅ All Checks Passed — Ready for Review

Check Status Details
📝 PR Description ✅ Pass —
⛔ Forbidden Files ✅ Pass —
🧪 Unit Test ✅ Pass —
🔎 pre-commit ✅ Pass —
🚫 Draft PR 🔜 To Be Enabled —
🚩 Feature Flag 🔜 To Be Enabled —
📊 Code Coverage 🔜 To Be Enabled —
🤖 therock-pr-bot ✅ Pass —

🎉 All checks passed! This PR is ready for review.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

@therock-pr-bot

Copy link
Copy Markdown

🎉 All checks passed! This PR is ready for review.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The narrow tooling change matches the intended behavior, preserves existing failure handling, and has focused regression coverage with no unresolved findings.

No open issues 🎉

What changed in this PR

Adds per-toolchain-flavor exceptions to rocKE’s strict IR validity gate, allowing expected compiler limitations without accepting unrelated unvalidated cases. No IR emission code changes.

Changes:

  • Defines skip lists for llvm20, llvm22, and llvm23.
  • Makes strict runs reject unlisted unvalidated cases and stale entries that now validate, while preserving non-strict exit behavior.
  • Adds tests for skip-list verdicts, selection boundaries, unknown flavors, and corpus references.
File Description
dnn-providers/​hip-kernel-provider/​rocke/​platform/​tools/​check_ir_validity.py Adds flavor-specific skip lists, verdict checks, and diagnostics.
dnn-providers/​hip-kernel-provider/​rocke/​platform/​tests/​core/​test_arch_domain_artifact.py Adds focused skip-list regression tests.

Review effort: Balanced

@cgmillette

Copy link
Copy Markdown
Contributor

Automated review: Model - qwen3.6:35b-a3b-coding-mtp-q4_K_M, effort: max

PR #14211 — add a per-flavor skip-list to the IR validity gate — 🟢 First-round: no closer look needed — the skip-list logic is right; the red CI checks come from develop, not this PR

Prior item Status
Copilot (10-22): approval recommended, no open issues 🟢 Agreed
Bots / CI 🟠 The HipDNN Linux superbuild fails in hipdnn_ingestor_generator_pytest: four tests in test_verify_variant_sets_multi_launch_rocke.py stop with "hipcc not found". That file came in with develop #14158 (10-22), which this PR's base includes, and develop's last scheduled superbuild predates it. So this is a develop break, not this PR (read). The Multi-Arch failures come from a run that was cancelled at start and replaced by a second run, which is still in progress. pre-commit, clang-tidy, the ASAN summary and Component CI pass
Our checks 🟢 The new tests pass on the merge: 51 passed, and the one skip is the regeneration check, whose flavor does not match this host (ran). The merge is clean (2 behind); rule_scan is clean (ran). On ROCm with LLVM 24 (this host), rocke resolves the llvm23 flavor and the gate refuses the llvm24 clang, so --strict exits 1 before the skip-list applies; develop does the same (ran). With --force, 239 / 246 cases validate. The 7 failures are exactly the gfx950 fp16 scalar-attention cases ("Operand has incorrect register class") that the description reports from the second llvm23 build, so that failure also reaches current ROCm (ran)
# Sev file:line Finding
N1 🟡 tools/check_ir_validity.py (flavor check) Before the gate runs in CI, note that on an LLVM 24 ROCm the host flavor (llvm23) and the clang (llvm24) disagree. --strict then reports UNVALIDATED and exits 1 whatever the skip-list says → decide how an llvm24 host maps (a flavor entry, or a documented "use an llvm23 image"), together with the 7 gfx950 compile failures above.

Utility: 🟢 Positive — lets the strict gate pass on llvm20 / llvm22 images while still failing on any new unmeasured case or stale entry; a needed step toward running it in CI.


Legend: 🔴 blocking · 🟠 should-fix · 🟡 minor nit · 🟢 info/good · ⚪ retracted

First-round review: a local qwen3.6 model made the independent first pass. The orchestrator (Claude Opus 5.5) verified it with the new tests on the merge, the strict gate on an LLVM 24 host (native and forced) against develop, and the failing CI log traced to its source, and owns this merge-worthiness call. It flags whether a closer look is needed; it is not an approval or a rejection.

@shumway

shumway commented Oct 22, 2026

Copy link
Copy Markdown
Contributor

I've been fixing this test because it's a blocker for running tests locally. I'm also adding it to CI on TheRock. If we can hold off on this PR until I get my changes in that would be much better.

@CongMa13

Copy link
Copy Markdown
Contributor Author

I reviewed this PR again. The following review threads are still unresolved, or comments have no author reply:

If you have already fixed these, please reply on each comment to say so and resolve the threads. Please request my review again once all comments and threads are resolved.

@CongMa13 CongMa13 left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No new issues found.

@cgmillette

Copy link
Copy Markdown
Contributor

@shumway can you request changes until your work lands? I want the bots to understand the dependency you highlighted.

@shumway

shumway commented Oct 23, 2026

Copy link
Copy Markdown
Contributor

The seven failing LLVM 23 test may be the ones I documented in #14084

CongMa13 and others added 2 commits October 26, 2026 12:59
Under --strict, `check_ir_validity.py` failed on any UNVALIDATED case.
A host with an older clang cannot measure some gfx1250 cases. The gate
could not run in CI on the llvm20 and llvm22 toolchains for that reason.

Add `SKIP_UNVALIDATED`, a table of the cases each flavor is expected to
leave UNVALIDATED, with a reason for each. Under --strict:

- A listed UNVALIDATED case passes.
- An UNVALIDATED case that is not listed fails.
- A listed case that now validates is stale and fails.

The list only shrinks, like `KNOWN_BAD`. A flavor with no entry expects
no UNVALIDATED case. Runs without --strict keep their behavior.

ISSUE ID : AICK-2694

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The gate printed one total for validated, known-bad and UNVALIDATED
cases. A run could not show which arch lost coverage.

Print a table of validated, failed and unvalidated counts for each arch.
The table counts every case once, so its rows add up to the corpus.

ISSUE ID : AICK-2694

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@CongMa13
CongMa13 force-pushed the users/congma13/rocke/ir-validity-skip-list branch from 5191e44 to d84f6ba Compare October 26, 2026 17:05
@cgmillette

Copy link
Copy Markdown
Contributor

Automated review: Model - qwen3.6:35b-a3b-coding-mtp-q4_K_M, effort: max

PR #14211 — add a per-flavor skip-list to the IR validity gate — 🟢 Follow-up: no closer look needed — the new per-arch table adds up to the corpus, and the red CI is develop's break plus a timeout this diff cannot reach. Check that shumway's hold is lifted before merging

Prior item Status
Our N1 🟡 (10-22): on an LLVM 24 ROCm, the host flavor (llvm23) and the clang (llvm24) disagree 🟡 OPEN, now tracked outside this PR.
• Unchanged here: --strict still exits 1 as UNVALIDATED before the skip-list applies (ran).
• CI's toolchain is now AMD clang 24 as well: at this head, rocke_arch_domain_reproducibility skips with the same flavor message (read). shumway's draft #14415 adds an LLVM 24 lane.
• With --force, 277 / 284 cases validate. The 7 failures are the same gfx950 fp16 scalar-attention cases ("Operand has incorrect register class") that #14084 tracks as an LLVM -O0 backend bug (ran)
shumway (10-22): hold this PR until their test work lands; (10-23) #14084 for the seven LLVM 23 failures 🟡 Probably satisfied; shumway should confirm. #14160 (10-24), #14355 and #14359 (10-26) have merged, and this PR merges cleanly on top of them (ran). No changes-requested review was filed, so GitHub does not record the hold
Copilot (10-22), CongMa13 (10-22) 🟢 No open threads (read)
Bots / CI 🟢 The red checks at d84f6ba4 do not come from this PR (read).
• Both hipDNN superbuilds fail on develop's break (KeyError: 'kernel_source' in the corpus desk check, and hip_kernel_provider_tests); #14412 fixes it.
• gfx94X hipkernelprovider shard 2 fails one test: a 60 s pytest-timeout while lowering in test_gdn_decode_fused.py::test_lowers_and_compiles_without_scratch. Neither of this PR's files takes part in that test.
• The gfx110X Windows tests are still queued. pre-commit, clang-tidy, the ASAN summary and the other gfx94X lanes pass
Our checks 🟢 The new commit d84f6ba4 prints a validated / failed / unvalidated table for each arch. On a clean merge with today's develop, its 8 rows sum to 277 / 7 / 0, which matches the 284-case corpus (ran). The PR's tests pass: 77, with 5053 subtests (ran). rule_scan is clean (ran)
# Sev file:line Finding
N1 🟡 tests/tools/test_arch_domain_artifact.py CI never runs the new ValiditySkipListTest / ValidityArchSummaryTest or the gate itself. The platform install excludes test_arch_domain_artifact.py, and check_ir_validity.py runs only from tools/run_checks.py (read). The check that the list "only ever shrinks" therefore runs only when someone runs the gate locally. This predates the PR → no change needed here; worth adding the gate to a lane once the LLVM 24 lane lands

Utility: 🟢 Positive — the skip-list lets the strict gate pass on llvm20 / llvm22 images while still failing on any new unmeasured case or stale entry. The per-arch table shows which arch lost coverage.


Legend: 🔴 blocking · 🟠 should-fix · 🟡 minor nit · 🟢 info/good · ⚪ retracted

Follow-up review: a local qwen3.6 model made the independent first pass. The orchestrator (Claude Opus 5.5) verified it. The checks were a range-diff against the head we reviewed and the PR's tests on a merge with today's develop. They also included the gate under --strict and --force on an LLVM 24 host, with the per-arch rows summed against the corpus, and the failing CI logs traced to their sources. The orchestrator owns this merge-worthiness call. It flags whether a closer look is needed; it is not an approval or a rejection.

@cgmillette cgmillette left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, @shumway please weigh in on current readiness

@CongMa13

Copy link
Copy Markdown
Contributor Author

This solution hides the problem instead of solving it. Close it and open another PR to solve this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants