[mlir] Remove filtering of deprecated rocm-agent-enumerator value gfx000

[MixedMatched]

Getting a gfx000 result from the rocm-agent-enumerator command was deprecated beginning with the release of ROCm 7, but the MLIR build system still filters it from results when looking for ROCm agents. This PR removes that filtering.

There are a few other uses of "gfx000" in MLIR source, but those are used as default options for running some passes, and, to my understanding, have a semantically different meaning to the dummy result returned from rocm-agent-enumerator and don't need to be changed.

[llvmbot]

@llvm/pr-subscribers-mlir

@llvm/pr-subscribers-mlir-execution-engine

Author: alessandra simmons (MixedMatched)

Changes

Getting a gfx000 result from the rocm-agent-enumerator command was deprecated beginning with the release of ROCm 7, but the MLIR build system still filters it from results when looking for ROCm agents. This PR removes that filtering.

There are a few other uses of "gfx000" in MLIR source, but those are used as default options for running some passes, and, to my understanding, have a semantically different meaning to the dummy result returned from rocm-agent-enumerator and don't need to be changed.

---

Full diff: https://github.com/llvm/llvm-project/pull/166634.diff

1 Files Affected:

• (modified) mlir/lib/ExecutionEngine/CMakeLists.txt (-1)

diff --git a/mlir/lib/ExecutionEngine/CMakeLists.txt b/mlir/lib/ExecutionEngine/CMakeLists.txt
index fdeb4dacf9278..a7337f9afd596 100644
--- a/mlir/lib/ExecutionEngine/CMakeLists.txt
+++ b/mlir/lib/ExecutionEngine/CMakeLists.txt
@@ -323,7 +323,6 @@ if(LLVM_ENABLE_PIC)
       endif()
       string(STRIP AGENTS_STRING ${AGENTS_STRING})
       string(REPLACE "\n" ";" AGENTS_LIST ${AGENTS_STRING})
-      list(FILTER AGENTS_LIST EXCLUDE REGEX "gfx000")
       if (AGENTS_LIST STREQUAL "")
         message(SEND_ERROR "No non-CPU ROCm agents found on the system, and ROCM_TEST_CHIPSET is not defined")
       else()

[lamb-j]

Looks good to me, rocm-agent-enumerator hasn't generated gfx000 for a few releases now, so it should be safe to stop checking for it. @krzysz00 any tests we should run to make sure this isn't impacting MLIR?

[krzysz00]

Does it hurt to keep this backwards compatibility logic around for a bit longer?

[krzysz00]

(And yeah, all the other uses of gfx000 I'm aware of are being used to create a plausible invalid chipset)

[lamb-j]

Does it hurt to keep this backwards compatibility logic around for a bit longer?

At some point the cost of the confusion of seeing gfx000 around may be higher than the benefit of backwards compatibility. Hard to say exactly where that point is.

We removed that behavior from rocm-agent-enumerator at the beginning of ROCm 6. We had a task to clean this up for ROCm 7, and we're just now getting around to it ahead of ROCm 8.

I'm not opposed to keeping it around to be safe. I don't know of a use case for an old rocm-agent-enumerator with a current or future MLIR, but I can't say for sure that doesn't exist out there somewhere.

[krzysz00]

Oh, if it's been gone since ROCm 6, we're well into "that old version's not supported" territory, lgtm