AMDGPU: Strategy for handling legacy architecture lit tests (gfx6/7/8, Kaveri, Tahiti)

[lamb-j]

Problem Statement

A large number of AMDGPU lit tests target legacy architectures (gfx6/7/8, Kaveri, Tahiti / SI, R600) that are perceived as largely unused today. There is no clear guidance on whether these tests should be retained, reorganized, migrated, or removed, and removal carries non-trivial risk.

This issue is to track discussion and converge on a strategy.

Note on where work lands: Any actual changes (test reorganization, backend split, deprecation) must be made upstream in llvm/llvm-project, not in this ROCm/llvm-project fork. This issue is filed here for visibility and tracking within the ROCm team, but the implementation path is through upstream LLVM review.

Observations

• Tests encode real backend coverage. Many tests are tightly coupled to architecture-specific behavior and code paths; blind removal would lose coverage even where the hardware is obsolete.
• The LLVM AMDGPU backend is still the fallback for older architectures. ACO only supports gfx9+, and Mesa continues to support the full lineup, so the LLVM path for legacy targets is still load-bearing downstream.
• Ecosystem inertia is significant. Triples, arch names, and feature strings are hardcoded across bash scripts, CMake, and other tooling. Renaming or removing has a wide blast radius and risks breaking downstream users.
• R600 vs GCN/AMDGPU is a recurring source of confusion. Splitting R600 into its own backend directory (lib/Target/R600/ vs lib/Target/AMDGPU/) has been raised repeatedly as a cleaner intermediate step than removal — it clarifies boundaries and allows independent enable/disable.
• Realistic lifecycle is multi-release. Even for clearly obsolete targets, the path is separate → deprecate → remove, on the scale of multiple releases (years), not a cleanup pass.

Open Questions

• Should legacy tests be:
  • Kept indefinitely?
  • Tagged / isolated into a separate tier (legacy vs active)?
  • Migrated to newer targets where coverage overlaps?
• Can we audit what backend behavior each legacy-target test actually protects, to distinguish "architecture-specific coverage" from "happens to use an old triple"?
• Should test cleanup be sequenced behind an R600 backend separation?
• What is the right deprecation signal to downstream users (Mesa, build systems, distros) before any removal?

Proposed Directions

Short term

• Preserve existing tests.
• Audit which legacy-target tests protect architecture-specific code paths vs. those that are incidental.

Medium term

• Organize tests by architecture class so the legacy surface is visible and manageable.
• Align test reorganization with a possible R600 vs AMDGPU backend split.

Long term

• Staged deprecation (separate → deprecate → remove) tied to backend support lifecycle and downstream readiness.

Background

Summary derived from an internal Teams discussion on whether legacy lit tests can be removed from the AMDGPU backend. The consensus was that modularization should precede removal, and that the LLVM AMDGPU backend remains the practical fallback for pre-gfx9 hardware.