[danielbolsson]

JIRA ID : AIRUNTIME-2937

Motivation

#13004 re-added hipKernelSetAttributeForDevice to HipDispatchTable on develop without regenerating the HRR sources. The checked-in capture and playback dispatch sources, hrr_api_args.h and the API matrix expectations no longer match the HIP headers, so the Generated sources check added in #13256 fails on develop. This PR regenerates them.

While regenerating, the API matrix turned out to carry further drift: the checked-in hrr_api_matrix_expectations.h and api_classes_baseline.json were hand-maintained rather than regenerated, so a number of expectations no longer matched the derived classification. In particular hipMallocHost / hipFreeHost were committed as NOOP while the generator derives them MANUAL / REAL (they are listed in MANUAL_PLAYBACK_APIS), which made Unit_HRR_ApiMatrix_T2_Roundtrip fail on a real GPU. That drift and the missing guard are folded in here from #13500, which this PR supersedes.

Technical Details

• Generated sources: re-run gen_hrr_api_args.py --check-hrr-coverage. Nothing in them is edited by hand.
• Classification of the new API:
  • Capture records it through a generated shim.
  • Playback is a no-op. Its hipKernel_t argument is one of the opaque types playback cannot turn back into a live object (_UNTRANSLATED_PLAYBACK_TYPES), so playback_defaults_to_noop applies without listing it anywhere. Its sibling hipKernelSetAttribute is a no-op for the same reason.
  • The API matrix lists it under unreachable, group absent-from-sdk-headers. The SDK headers the matrix workloads compile against do not declare it, so no workload can call it.
• API matrix: derive_manifest.py --update-baseline, then check_matrix.py --emit-cxx. The baseline gains one runtime API, one generated capture and one no-op replay, and the derived expectations and baseline counts are re-derived from source rather than hand-edited. Re-running both steps on this tree is a no-op; on unmodified develop they change the checked-in files, which is the drift this fixes.
• HRR_VERSION goes from 8 to 9. The new runtime slot takes the first compiler API ID and shifts the compiler IDs up by one, so a v8 reader would decode those events as the wrong API. The version history in DESIGN.md and the generator's header comment record v9.
• New guard: projects/hrr/tools/tests/test_generated_files_current.py regenerates hrr_api_args.h, both generated dispatch sources and the API matrix expectations into a scratch directory and fails if the checked-in copies differ. The matrix tests that caught the drift above are not part of the default suite, so this makes staleness fail loudly in CI instead.

Issue Tracking

Fixes the Generated sources failure on #13256 that comes from develop. Supersedes #13500.

Test Plan

• hrr_check_sources.py all --base-sha origin/develop (from ci(hrr): add the HRR CI workflow #13256), on this branch and on an unmodified develop.
• pytest projects/hrr/tests/scripts and pytest projects/hrr/tools/tests.
• Build CLR with HRR capture, then HRR playback, unit and integration tests, against an in-tree ROCr. Run the host-only unit tests.
• On gbt350 (2x MI350X, gfx950, HIP_VISIBLE_DEVICES=4,5): the API matrix roundtrips T0-T5 and the full integration gate.

Test Result

• hrr_check_sources.py: generated sources, API-ID compatibility (8 to 9) and the API matrix all pass. On develop the generated-sources and API-matrix checks fail on this API alone.
• pytest projects/hrr/tests/scripts: 138 passed.
• pytest projects/hrr/tools/tests: 18 passed, including the two new staleness tests.
• Build: ROCr, CLR with HRR capture, and HRR playback, unit and integration tests (gfx950) all build, and both regenerated dispatch sources compile with the new API. The host-only unit tests pass (32 test cases), and the integration binary lists 127 test cases.
• gbt350, HIP_VISIBLE_DEVICES=4,5 (2x MI350X, gfx950), results attributable to this commit (drovr-sync tree id matched): API matrix roundtrips T0-T4 pass (8 tests), T5 passes (1032 assertions), and the full integration gate reports 159 passed / 1 skipped / 0 failed. check_matrix.py --results reports fail=0 in every tier.
• Two pre-existing conditions, reproduced without this change and not caused by it: check_matrix.py's analyzer exits 1 on two T5 coverage notes (hipArray3DCreate / hipArrayCreate neither exercised nor declared unreachable), and the host handler-tests report a 384-byte ASan leak inside ROCr (hsaKmtCreateEventCtx) with all 220 assertions passing.

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

[therock-pr-bot]

✅ All Policy Checks Passed

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—

🎉 All policy checks passed!

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

🙋 Wish to Override Policy?

[andraghetti]

The regeneration and the v9 bump look right: the new slot takes ID 547 and the nine compiler IDs move up by one. On MI350 at 6327b8f the full gate shows only the known baseline failures; T0–T2, T5, ManifestWellFormed and ReplayClassMarkers pass. Approving.

[mangupta]

🤖 AI-assisted pre-review (for @mangupta)

Re-reviewed the updated head (da05d0e90e4d) — no new findings at or above the posting threshold.

[mangupta]

🤖 AI-assisted pre-review (for @mangupta)

Re-reviewed the updated head (439eb5f229d2) — no new findings at or above the posting threshold.

[AlexXAmd]

approve the CLR repo code change.

[systems-assistant]

TheRock Submodule Bump Activity

Newest first

• 2026-10-19 — Included in TheRock via ROCm/TheRock#9353.