[BugFix][LLVM] Fix insertDeclare API mismatch for ROCm-bundled LLVM 20

[swjng]

Problem

Closes #18709.

ROCm ships its own LLVM 20 build that still uses the pre-LLVM-20 Instruction* overload of DIBuilder::insertDeclare, while upstream LLVM 20 switched to BasicBlock::iterator. The previous guard #if TVM_LLVM_VERSION >= 200 in codegen_llvm.cc broke ROCm users because their LLVM reports version 20 but lacks the new overload, causing a compile error like:

error: no matching function for call to
  'llvm::DIBuilder::insertDeclare(..., llvm::BasicBlock::iterator)'
note: candidate: insertDeclare(..., llvm::Instruction*)

Fix

Replace the version-number guard with a CMake check_cxx_source_compiles feature probe in cmake/utils/FindLLVM.cmake. The probe compiles a small test program that calls insertDeclare with BasicBlock::iterator. The result is exposed as the preprocessor macro TVM_LLVM_INSERTDECLARE_USES_ITERATOR.

cmake_push_check_state/cmake_pop_check_state is used to avoid leaking CMAKE_REQUIRED_* variables into the rest of the build.

Three call sites in src/target/llvm/codegen_llvm.cc are updated to use #if TVM_LLVM_INSERTDECLARE_USES_ITERATOR instead of #if TVM_LLVM_VERSION >= 200.

Behavior by configuration:

LLVM build	Probe result	Macro set	Code path
Upstream LLVM >= 20 with new overload	Compiles	Yes	BasicBlock::iterator
ROCm LLVM 20 (old overload)	Fails	No	Instruction*
Any LLVM < 20	Probe skipped	No	Instruction*

Testing

Tested locally with LLVM 20.1.8 (Ubuntu package):

tests/python/codegen/test_target_codegen_llvm.py  39 passed

[gemini-code-assist]

Code Review

This pull request introduces several fixes and improvements to the TVM build and compilation pipelines. It adds CMake feature detection for LLVM 20's DIBuilder::insertDeclare to handle differences between upstream and ROCm-bundled versions. In the Relax VM build, it now prefers target-specific pipelines when using the "default" configuration. The compile_relax integration for MetaSchedule was refactored to ensure a correct pass ordering, including DLight fallback scheduling. Additionally, safety checks were added to TIRX passes to handle functions without defined targets. Feedback suggests improving the target-specific pass detection in the MetaSchedule integration to support backends beyond CUDA, avoiding manual duplication of pass lists, and ensuring CMake variable state is preserved during feature detection.

[tlopex]

Two points are worth addressing before merging:

1. MSVC compatibility in the feature probe

In cmake/utils/FindLLVM.cmake, the probe currently sets:

set(CMAKE_REQUIRED_FLAGS "-std=c++17 -fno-rtti")

These are GCC/Clang-style flags. Under MSVC, they are not recognized (/std:c++17 and /GR- are the corresponding forms), so check_cxx_source_compiles can fail for reasons unrelated to the API being tested. In that case, TVM_LLVM_INSERTDECLARE_USES_ITERATOR remains unset and the code falls back to the Instruction* path, which will break for an MSVC build against upstream LLVM 20 where only the BasicBlock::iterator overload exists.

At minimum, this probe should handle MSVC separately. Also, -fno-rtti does not seem necessary for a signature-only probe, so I would drop it. It may be even cleaner to rely on CMAKE_CXX_STANDARD rather than hardcoding a -std= flag here.

2. The macro name does not match all gated call sites

The macro is named TVM_LLVM_INSERTDECLARE_USES_ITERATOR, but in codegen_llvm.cc it is also used to guard a call to insertDbgValueIntrinsic, not just insertDeclare.

That raises two issues:

• The name is misleading for future readers.
• The probe only checks insertDeclare, so it assumes both APIs always change together. That is true for upstream LLVM 20, but it is a brittle assumption if a downstream fork diverges.

I think this should be generalized: use a broader macro name (for example, something DIBuilder-wide), and make the probe test both insertDeclare and insertDbgValueIntrinsic. Then update the corresponding #if sites in codegen_llvm.cc to use that broader macro.