[TEST] ROCm mlir_aie wheel on Ryzen AI self-hosted runners

[jgmelber]

Summary

Adds .github/workflows/testRocmWheelOnRyzenAI.yml to validate the ROCm-built mlir_aie wheel against real Ryzen AI NPU hardware before promoting it into the production mlir-distro pipeline.

• Build: builds mlir-aie against the current rocm-mlir-distro release wheels (same commit that already passed the (now-closed) [TEST] Add ROCm migration test workflow #3314 migration test), on ubuntu-22.04.
• Test: pip-installs the resulting wheel exactly as a real IRON user would (not a from-source build), then runs the programming_examples/ Makefile-driven examples on self-hosted NPU runners (aie2-4col, aie2p-8col), via a new utils/run_programming_examples_from_wheel.py that replays each example's *.lit file REQUIRES/RUN metadata directly.

Scope note: test/ and programming_guide/ are intentionally not covered here — their lit suites need a CMake-configured lit.site.cfg.py (confirmed: find_package(AIE CONFIG) standalone-configure fails today because the wheel's AIEConfig.cmake doesn't export imported executable targets like aie-translate that add_lit_testsuite's DEPENDS expects — fixing that is its own, separate CMake-export task). buildAndTestRyzenAI.yml already covers those two suites via a from-source build.

This PR should run and pass before merging the companion "bump MLIR distro to ROCm/llvm-project" PR, per the plan to validate on CI hardware first.

Test plan

• Manually dispatch this workflow and confirm build_wheel succeeds
• Confirm test_examples_on_hardware runs on both aie2-4col and aie2p-8col and the programming_examples summary shows passes with no unexpected failures

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds a dedicated GitHub Actions workflow to build the ROCm-based mlir_aie wheel and validate it by running programming_examples/ directly on self-hosted Ryzen AI NPU runners, using a new helper script that replays *.lit metadata without requiring a CMake/lit build tree.

Changes:

• Introduces .github/workflows/testRocmWheelOnRyzenAI.yml to build the wheel against rocm-mlir-distro, install it in a fresh venv, and run programming_examples/ on aie2-4col and aie2p-8col hardware runners.
• Adds utils/run_programming_examples_from_wheel.py to parse REQUIRES/RUN (and XFAIL) from makefile-oriented *.lit files and execute them via run_on_npu.py.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
utils/run_programming_examples_from_wheel.py	Implements lit-file parsing and Makefile example execution against a pip-installed wheel on hardware runners.
.github/workflows/testRocmWheelOnRyzenAI.yml	New CI workflow to build the ROCm wheel and validate it by running programming examples on Ryzen AI NPUs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jgmelber]

Root cause of the `Run programming_examples` failures on both `aie2-4col` and `aie2p-8col`

Both hardware legs fail identically (0/42 and 0/46 passed), overwhelmingly (35/42, 39/46) with:

```
RuntimeError: [aiecc] Compilation failed with exit code 1:
Error: Command failed with exit code -2
Error message: Segmentation fault (core dumped)
Error generating PDI
```

This is a real, hardware-independent packaging bug in this wheel's `bootgen` binary — not a flake or missing-hardware artifact. Diagnosis:

• Comparing this wheel's `bootgen` against the current officially-released `mlir_aie` wheel's `bootgen`:
  • Official: `ELF ... pie executable` (`ET_DYN`) — runs fine (`bootgen -help` prints the normal banner).
  • This wheel: `ELF ... EXEC (Executable file)` (non-PIE) — segfaults immediately, even under `LD_TRACE_LOADED_OBJECTS=1` (what `ldd` uses internally), i.e. the dynamic loader crashes before `bootgen`'s own code ever runs.
• `strace` shows the actual mechanism: `SIGSEGV` with `si_code=SEGV_ACCERR` (access-permission violation on a mapped page, not a wild pointer) at address `0x4020c8`.
• `readelf -l` shows that address falls inside the `DYNAMIC` program header segment, which is mapped `RW` only (no execute permission). Something is jumping there to execute code — the signature of a corrupted GOT/PLT entry or bad relocation.
• `bootgen` has no dependency on MLIR/LLVM at all (it only links `OpenSSL::SSL` + its own `bootgen-lib`), so the PIE→non-PIE flip has to come from a global CMake/compiler flag that changed when configuring against the ROCm-built MLIR package's exported `LLVMConfig.cmake`/`HandleLLVMOptions.cmake` (both execute once at the top of `cmake configure` and apply to every target in the same build, `bootgen` included) — not anything ROCm-specific in `bootgen`'s own build rules.
• `auditwheel repair`'s `patchelf`-based RPATH rewrite (needed to point at vendored/renamed OpenSSL libs) appears to mishandle this non-standard `EXEC`-with-dynamic-libs layout, corrupting the binary during that patch — a known-ish `patchelf` weak spot with non-PIE executables, just newly triggered here.

This blocks both this PR and #3326 until fixed. Proposed fix (as a follow-up PR): force `POSITION_INDEPENDENT_CODE ON` on the `bootgen`/`bootgen-lib` CMake targets directly, so they no longer depend on whatever global flag differs in this build — sidesteps the root cause rather than trying to fix `patchelf`/`auditwheel` itself.