[newling]

rocjitsu's floating-point tests check lots of combinations of instructions, architectures, operands and mode settings. Each combination is a GoogleTest case, and CTest currently starts a fresh rocjitsu_tests process for each one. Every process builds and registers the whole parameter matrix before GoogleTest applies the filter for the one case it needs to run. So adding cases makes every launch more expensive, including launches for unrelated tests.

This showed up in the TheRock emulation timing discussion: the emulation test step grew from 13m17s to 62m41s after the FP matrices expanded. Most of the extra time was going into repeated startup work.

This change puts valu_fp_mode_test.cpp in its own executable, rocjitsu_fp_mode_tests, and runs it in 16 GoogleTest shards (batches). Each batch still registers the full FP matrix, but that now happens 16 times instead of once per case. The other tests no longer register the FP matrix at all. The parameter grids, assertions and fresh emulator setup for each case stay the same. GoogleTest assigns every case to one batch, so new cases are picked up automatically. The 16 batches follow CTest's usual parallelism setting; they also work with a single worker.

If you build everything and run ctest, the workflow stays the same. Both the build tree and installed tests include the new executable and all 16 batches. To run just the FP tests:

ctest --test-dir build -L '^fp-mode$' --output-on-failure

If you use ctest -R to select an individual FP case or family, those names are now inside the batches. Use the new executable with a GoogleTest filter instead; for example:

build/tests/rocjitsu_fp_mode_tests --gtest_filter='BinaryF32/ValuFpModeTest.*'

Scripts that build or run only rocjitsu_tests also need to include rocjitsu_fp_mode_tests to keep running the FP coverage.

Each batch uses a small CMake launcher that removes its previous XML before starting GoogleTest and fails the CTest batch if cleanup fails. The launcher passes --gtest_filter=* so an inherited GTEST_FILTER cannot silently reduce coverage, and --gtest_brief=1 to suppress passing-case chatter while retaining failure diagnostics and per-case XML. Direct executable invocations can still use custom filters.

CTest reports ValuFpModeTest.Shard0 through Shard15, so its test count drops even though the same cases run. ctest --rerun-failed reruns a failed batch. GoogleTest writes per-case XML under build/tests/gtest-results/ (or gtest-results/ in the installed test directory) when it finishes the batch. Ordinary assertion failures let the batch continue; a crash or timeout stops the remaining cases. If the launcher cannot start or complete cleanup, an older report can remain, so read the XML alongside CTest's status. The README documents the selection commands and result locations.

The controlled before and after CI runs measured the original batching change at a7cc536f7f15, before the launcher follow-up and subsequent rebases. They used the same TheRock revision, container and two-CPU runner class, with one CTest worker:

Measurement	Before	After
Entire emulation test step	67m27s	14m36s
rocjitsu CTest wall time	3867.92 s	695.79 s
FP cases/batches, sum of reported durations	2252.58 s	3.23 s
mirage CTest wall time	178.46 s	179.27 s

That saves 52m51s, about 78% of the emulation test step, in this paired run. These timings exclude compilation and artifact handling. The 67m27s baseline is from this experiment; the earlier 62m41s is the motivating historical run.

All 16 FP batches passed. Both runs still have the same 223 failing non-FP tests, with identical names and failure statuses. Those tests are non-blocking in TheRock, so the successful job results don't mean the whole suite passes. The four regular rocjitsu CI configurations (Release, ASan/UBSan, TSan and GCC UBSan) also passed before the launcher follow-up.

Initial local validation of the batching change with Clang 23.1 in Release mode preserved the original 37,795 GoogleTest cases exactly as 5,911 main cases plus 31,884 FP cases. Those are counts from that revision. The batch XML confirmed every FP case passed exactly once, both in the build tree and after relocating the installation. Three shuffled repetitions passed too. Main-executable startup fell from 72.9 ms to 10.4 ms locally; the build and install passed.

The launcher follow-up was checked with freshly generated build-tree and installed CTest commands using the retained FP binary with unchanged test source. All 31,884 FP cases ran exactly once despite an unmatched inherited filter, including after relocating the installed tests to a path containing spaces. Focused probes checked deletion errors, symlinks, crashes, assertion failures, timeouts and failed-batch reruns; permission checks ran on CMake 3.28 and 4.4. Formatting and whitespace checks pass. A full local rebuild was not repeated for the launcher follow-up or final rebase.

ISSUE ID: ROCm/TheRock#8670 (comment)

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

[therock-pr-bot]

✅ All Checks Passed — Ready for Review

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	PR does not contain code files — Unit Test auto-passed
🔎 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]

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

[kuhar]

Just one comment

[Groverkss]

Thanks for doing this! LGTM after Jakub's comment.

[kuhar]

Two small suggestions from our local validation of the same FP matrix:

1. Pass "--gtest_filter=*" in both COMMAND and INSTALL_COMMAND. The old discovered CTest cases supplied explicit filters; the new shard commands inherit GTEST_FILTER. With identical FP test source and the shard-0/16 command/environment from this PR, GTEST_FILTER=DefinitelyMissingSuite.DefinitelyMissingTest made CTest report success and write XML containing 0 tests. Adding the explicit filter restored all 1,993 passing cases in that shard. This prevents a leftover shell-level filter from silently reducing the coverage of ctest -L fp-mode; direct executable invocations can still use case-specific filters.

2. Consider --gtest_brief=1 in both commands. For the same shard, verbose CTest output dropped from 472,635 bytes to 1,196 bytes. The XML still contained exactly the same 1,993 case identities and results. Brief mode retains failure diagnostics while suppressing passing-case chatter, making failures easier to find in CI logs and reducing the risk of useful output being truncated.

These checks reused our existing FP binary with the same valu_fp_mode_test.cpp source as 9c0fc528bb68; no rebuild or full-suite run was needed.

[newling]

Hi @kuhar can you please take another look? The top 2 commits hopefully address the issues you flagged

[JeniferC99]

Cancelling the remaining gfx950 jobs on this run so the TheRock submodule bump PRs can be prioritized on the gfx950 queue.

This change does not target gfx950, and gfx950 was the only work still outstanding. Jobs that already finished are unchanged. Re-run failed jobs if you need gfx950 results before merge.

[Groverkss]

Cancelling the remaining gfx950 jobs on this run so the TheRock submodule bump PRs can be prioritized on the gfx950 queue.

This change does not target gfx950, and gfx950 was the only work still outstanding. Jobs that already finished are unchanged. Re-run failed jobs if you need gfx950 results before merge.

The gfx950 jobs shouldn't be anyway running on this PR after ROCm/TheRock#8670 . Would be good to verify.

[systems-assistant]

TheRock Submodule Bump Activity

Newest first

• 2026-10-08 — Included in TheRock via ROCm/TheRock#8831.