Bump IREE requirement pins to 3.8.0rc20250923

[shark-pr-automator]

Diff: iree-org/iree@iree-3.7.0rc20250828...iree-3.8.0rc20250923

Auto-generated by GitHub Actions using .github/workflows/update_iree_requirement_pins.yml.

pickup specialization microkernels for gfx950.
Refer to this IREE commit

Test result on gfx950 shows including the below compiling option when using iree-compile get better performance:
--iree-hip-enable-tensor-ukernels

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
sharktank
conftest.py
Project Total

This report was generated by python-coverage-comment-action

[dezhiAmd]

I am working on bump to 3.8.0rc20250909.
We need to disable a few llvm-compile-target-as-cpu.
please refer to
#2242

BTW, what fix, new feature is 3.8.0rc20250910?

[amd-vivekag]

I am working on bump to 3.8.0rc20250909. We need to disable a few llvm-compile-target-as-cpu. please refer to #2242

BTW, what fix, new feature is 3.8.0rc20250910?

Hi @dezhiAmd did you have any progress on this? Since I didn't hear from you since night, so I was also looking into it today and found that 2 more toyLlama tests started failing since following PR commit: iree-org/iree#21851

I'm adding xfail on those 2 testcases and will try to update the PR with latest IREE build.

[amd-vivekag]

XFailed 2 toy llama testcases and filed an issue for that: iree-org/iree#22015

[amd-vivekag]

@dezhiAmd I just noticed that you have already worked upon the xfailing testcases and created issues w.r.t. following PR: #2242

I'll let you continue on that now. I'm not making any changes further. we can close this PR once your PR gets merged.

[Alex-Vasile]

We should be doing our IREE bumps using these automated PRs. They insure we don't forget to change one of the files and they use a standardized naming scheme which makes it easy to find later.

Additionally, the automation will only run if this branch does not exist. We have done manual bumps before and forgot to delete this branch, leading to us staying on an old iree pin for weeks before realizing the issue.

[amd-vivekag]

We should be doing our IREE bumps using these automated PRs. They insure we don't forget to change one of the files and they use a standardized naming scheme which makes it easy to find later.

Additionally, the automation will only run if this branch does not exist. We have done manual bumps before and forgot to delete this branch, leading to us staying on an old iree pin for weeks before realizing the issue.

If that is the case, then I can continue on this, and will try to merge.

[amd-vivekag]

Somehow smoke tests are failing in CI but passing in my local run. Any suggestion what should I do locally to reproduce the issue?

[dezhiAmd]

Somehow smoke tests are failing in CI but passing in my local run. Any suggestion what should I do locally to reproduce the issue?

I reproduced the issue locally. And reported the iree issue here: iree-org/iree#22026

[dezhiAmd]

I am working on bump to 3.8.0rc20250909. We need to disable a few llvm-compile-target-as-cpu. please refer to #2242

BTW, what fix, new feature is 3.8.0rc20250910?

Also I am curious about the scenarios where compiling MLIR to a VMFB for a CPU target would be beneficial. From my understanding, AMD's strengths lie in GPU hardware, and AI inference workloads are typically GPU-accelerated. So I'm trying to better understand the rationale or use cases behind targeting the CPU in this context

[amd-vivekag]

We can revert changes in toy llama testcase because it has been fixed under PR: iree-org/iree#22010

[amd-vivekag]

I am working on bump to 3.8.0rc20250909. We need to disable a few llvm-compile-target-as-cpu. please refer to #2242
BTW, what fix, new feature is 3.8.0rc20250910?

Also I am curious about the scenarios where compiling MLIR to a VMFB for a CPU target would be beneficial. From my understanding, AMD's strengths lie in GPU hardware, and AI inference workloads are typically GPU-accelerated. So I'm trying to better understand the rationale or use cases behind targeting the CPU in this context

As far as I know, this is the rationale behind supporting CPU: the complete workflow should support both CPU and GPU because there are lot of light weight models which can be run on CPU.

[dezhiAmd]

Failure of [CI - sharktank / Unit Tests (linux-mi325-8gpu-ossci-nod-ai, 3.12, 2.6.0) is caused by this iree issue: https://github.com/iree-org/iree/issues/22018

[archana-ramalingam]

Failure of [CI - sharktank / Unit Tests (linux-mi325-8gpu-ossci-nod-ai, 3.12, 2.6.0) is caused by this iree issue: https://github.com/iree-org/iree/issues/22018

Do we wait for this issue to be fixed or plan on xfailing and landing this for now? Preferably the latter, as long as it's only impacting toy llama.

[amd-vivekag]

Failure of [CI - sharktank / Unit Tests (linux-mi325-8gpu-ossci-nod-ai, 3.12, 2.6.0) is caused by this iree issue: https://github.com/iree-org/iree/issues/22018

Do we wait for this issue to be fixed or plan on xfailing and landing this for now? Preferably the latter, as long as it's only impacting toy llama.

The error got changed it seems. So, I have created another issue for the same: iree-org/iree#22055
I'm not sure if xfailing the testcase is the right approach.

@rsuderman , @IanNod please share your thoughts.