AMD Vega (gfx900) が ROCm の公式推奨対象から外れた後も、なぜ複数のライブラリ経路で計算を実行できるのか。コードベース調査・実機検証・git 履歴調査に基づく、工学的構造分析を記録する。
An engineering investigation into why AMD Vega (gfx900) can still execute computation through multiple library paths in the ROCm stack, even after being removed from official support lists — based on source code tracing, runtime verification, and git provenance analysis.
現時点で最も堅い知見:
gfx900 が今も通れるのは、ROCm の設計が capability-based のフォールバック構造を持っているからである。この構造は gfx900 に限らず「能力が低い世代」全般に対して自然に働く。これは設計の寛容性であり、意図的か否かにかかわらず結果として後方互換が成立している。
Current strongest finding:
gfx900 remains functional because the ROCm stack employs a capability-based fallback architecture. This architecture naturally accommodates any generation lacking specific capabilities — not just gfx900. Regardless of whether this was intentional, backward compatibility is effectively maintained as a structural consequence of the design.
以下はすべてソースコード調査で根拠を確認した観測事項である。仮説ではない。
All items below are grounded in source code inspection and are factual observations, not hypotheses.
| 層 | 内容 | 具体例 |
|---|---|---|
| 維持 (Build) | ビルドシステムに gfx900 ターゲットが残存 | rocBLAS CMakeLists に ROCm 5.6–7.1 で gfx900 が継続 |
| 管理 (Selection) | Solver / kernel 選択で capability 判定が機能 | MIOpen の IsApplicable フィルタ、IsXdlopsSupport ガード |
| 補充 (Fallback) | 高速経路が使えないとき汎用経路へ落ちる | CK dot4 不在時の逐次積和、rocBLAS の XF32→FP32 フォールバック |
| Layer | Description | Example |
|---|---|---|
| Build | gfx900 target remains in build systems | rocBLAS CMakeLists: gfx900 listed in ROCm 5.6–7.1 |
| Selection | Capability-based solver/kernel selection | MIOpen IsApplicable filters, IsXdlopsSupport guard |
| Fallback | Generic paths activated when fast paths are unavailable | CK sequential multiply-add when dot4 is absent; rocBLAS XF32→FP32 fallback |
IsXdlopsSupport で gfx900 を弾くIsXdlopsSupportAsmCaps で ISA (9,0,0) の dot4 capability は FalseAsmCaps reports dot4 capability as False for ISA (9,0,0)dot4 不在時の逐次積和フォールバック（gfx900 専用ではなく汎用設計）dot4 is absent (generic, not gfx900-specific)Vega 64 実機上で MIOpen の solver 選択動作と DLOPS/XDLOPS 系の挙動を検証した結果。
Results from solver selection testing and DLOPS/XDLOPS behavior verification on a Vega 64.
FP32 畳み込みにおいて、以下の solver が Vega 64 上で自然選択されることを確認した:
The following solvers were naturally selected on Vega 64 for FP32 convolution:
ConvBinWinograd3x3U — Winograd 系ConvBinWinograd3x3U — Winograd familyConvAsm1x1U — 旧 ASM 系ConvAsm1x1U — Legacy ASM familyConvHipImplicitGemmV4R1Fwd — implicit GEMM v4r1ConvHipImplicitGemmV4R1Fwd — Implicit GEMM v4r1solver family ごとに到達点が異なり、失敗モードは以下の3類型に分かれた:
Each solver family fails at a different stage. Three distinct failure modes were identified:
| 類型 | 症状 | 例 |
|---|---|---|
| Applicability 棄却 | not applicable, rc=0x3 | ConvCkIgemmFwdV6r1DlopsNchw (全ケース) |
| Build / tuning 失敗 | MIIR_INVALID_PARAM / Perf Db: record not found / Code object build failed | ConvMlirIgemmFwd, ConvHipImplicitGemmForwardV4R5Xdlops |
| Runtime abort | std::vector::operator[] assertion, EXIT=134 | ConvHipImplicitGemmFwdXdlops |
| Mode | Symptom | Example |
|---|---|---|
| Applicability reject | not applicable, rc=0x3 | ConvCkIgemmFwdV6r1DlopsNchw (all cases) |
| Build / tuning failure | MIIR_INVALID_PARAM / Perf Db: record not found / Code object build failed | ConvMlirIgemmFwd, ConvHipImplicitGemmForwardV4R5Xdlops |
| Runtime abort | std::vector::operator[] assertion, EXIT=134 | ConvHipImplicitGemmFwdXdlops |
同一 3×3 問題で dtype を変えると、FP16 → ConvOclDirectFwd、BFP16 → GemmFwdRest が選択され、solver finder が dtype ごとに別経路を自然選択することも確認された。
Changing dtype on the same 3×3 problem yielded FP16 → ConvOclDirectFwd and BFP16 → GemmFwdRest, confirming per-dtype path differentiation by the solver finder.
以下はコード根拠に基づく仮説であり、断定ではない。確度を明示して記載する。
The following are hypotheses informed by code evidence, not assertions. Confidence levels are explicitly noted.
「サポート終了」とは、公式推奨リスト・QA 対象・優先修正対象から外れたことを意味する。しかしそれは、ソフトウェア設計上の実行経路が消滅することとは別の話である。
"End of support" means removal from official recommendation lists, QA targets, and priority fix queues. It does not necessarily mean the elimination of software execution paths.
| 層 | 定義 | gfx900 の現状 |
|---|---|---|
| 表のサポート | 公式推奨・QA対象・ベンチ対象・優先修正 | 弱い（公式リスト外） |
| 設計上のサポート | 抽象化・capability 判定・fallback・backend 切替 | まだ残っている |
| 運用上のサポート | バグ報告が通るか、CI にいるか | 確認中 |
| 生存可能性 | 明示的に守られていないが、設計のため動ける | 成立している可能性が高い |
| Layer | Definition | gfx900 status |
|---|---|---|
| Official support | Listed in official docs, QA-tested, benchmark-targeted | Weak (off-list) |
| Design-level support | Abstractions, capability checks, fallback, backend switching | Still present |
| Operational support | Bug reports accepted, present in CI | Under investigation |
| Survivability | Not explicitly maintained but structurally functional | Likely viable |
gfx900 が今も通れるのは「放置された残骸」ではなく、ROCm のライブラリ設計が後方互換・多段フォールバックを強く意識しているため、その設計の自然な結果として gfx900 が通れる経路が残っている、という読み方ができる。
Rather than being a neglected remnant, gfx900's continued functionality can be read as a natural consequence of ROCm's library design, which is built around backward compatibility and multi-stage fallback.
IsApplicable フィルタ方式であり、「ある世代が使えない経路は落として次へ」という汎用設計IsApplicable filtering: a generic design that drops unsupported paths and moves to the nextdot4 不在時の逐次積和は gfx900 専用ではなく、dot4 capability が立たない世代全般向けの汎用互換レイヤdot4 is absent is not gfx900-specific — it is a generic compatibility layer for any generation without dot4ここで重要なのは、「AMD かコミュニティか」を一語で決めるより、投入主体・維持主体・運用主体・修正可能主体を分けることです。
The key is not to force a single answer such as “AMD” or “community,” but to separate insertion ownership, maintenance ownership, operational ownership, and repair-capable ownership.
| 主体 | 問い |
|---|---|
| 投入主体 | その分岐やコードを最初に入れたのは誰か |
| 維持主体 | その後も壊れないように残し続けているのは誰か |
| 運用主体 | 見つけて、動かして、回避策を共有しているのは誰か |
| 修正可能主体 | その層の問題を現実に直せるのは誰か |
| Role | Question |
|---|---|
| Insertion owner | Who introduced the branch or code? |
| Maintenance owner | Who keeps it from breaking over time? |
| Operational owner | Who discovers, runs, and shares workarounds? |
| Repair-capable owner | Who can realistically fix the issue at that layer? |
gfx900 除外は AMD 社員 Zhuoran Yin の commit 2407d2f であり、private issue 参照も AMD 側にあるgfx900 exclusion was commit 2407d2f by AMD engineer Zhuoran Yin, with a private AMD-side issue referencegfx900 を超えて ROCm 一般の設計思想に広がるため、別ページ What gfx900 Reveals About ROCm に整理した。
Note: Because this question extends beyond gfx900 into ROCm-wide design, a separate page summarizes it: What gfx900 Reveals About ROCm.
AMD は rDNA（ゲーム向け）と cDNA（計算向け）を別系統で開発してきたが、2024年に UDNA による統合方向が示されている。もし毎回ぜんぶ切り捨てる設計なら、アーキテクチャが増えるたびにコンパイラ・ランタイム・ライブラリの保守コストが際限なく膨れる。ROCm のような大規模 OSS スタックが持続するには、どこかに共通化の芯が必要であり、結果として後方互換や抽象化の筋を残しておくのが合理的である。
AMD has developed rDNA (gaming) and cDNA (compute) as separate lines, but indicated a UDNA unification direction in 2024. If each new architecture completely discarded the old, compiler/runtime/library maintenance costs would grow without bound. A large-scale OSS stack like ROCm requires a shared abstraction core — making it rational to preserve backward compatibility and abstraction as a structural investment.
UDNA の正体そのものはまだ断言できない。しかし将来の再統合コストを下げるためには、後方互換や抽象化の筋をどこかに残しておくのが合理的である。現在のコードベース調査は、少なくとも「そう読めるだけの構造が存在する」ことをかなり強く支持している。したがって意図的設計だったか副産物だったかは保留しつつも、結果論として再統合しやすい形に寄っている可能性は高い。
The nature of UDNA cannot yet be determined. However, preserving backward-compatible abstractions is rational for reducing future re-integration costs. The codebase investigation strongly supports the existence of structures consistent with this reading. Whether this was intentional design or an emergent property remains open — but the result converges toward a re-integration-friendly form.
「なぜ残っているか」の答えとして、「設計の自然な帰結」と「コミュニティの保守」の二択で考えがちだが、実はもう一つある。コスト-便益的に「消すコストのほうが高いから残っている」という状態である。これは「積極的に維持している」とも「積極的に切り捨てている」とも違い、git blame で「誰も最近触っていない」という結果が出れば支持される。
When asking "why does it remain?", it is tempting to choose between "natural consequence of design" and "community maintenance". But there is a third state: it remains because the cost of removing it exceeds the cost of leaving it. This differs from both active maintenance and active deprecation, and would be supported by git blame results showing no recent modifications.
gfx900 の MLIR 除外がいつ・誰により・なぜ投入されたかの追跡結果。
Tracking who introduced the gfx900 MLIR exclusion, when, and why.
ConvMlirIgemmFwd::IsApplicable() における gfx900 明示除外について、git blame で provenance を確定した。
Provenance of the explicit gfx900 exclusion in ConvMlirIgemmFwd::IsApplicable() was established via git blame.
| 項目 | 内容 |
|---|---|
| コミット | 2407d2f556c7 |
| 著者 | Zhuoran Yin (zhuoryin@amd.com) — AMD 社員 |
| 日時 | 2021-12-22 |
| PR | MIOpen #1328: "[MLIR] Disable gfx900 from non-xdlops solver" |
| 参照 issue | ROCm/llvm-project-private/issues/389 — AMD 社内非公開リポジトリ |
| 影響範囲 | fwd / bwd / wrw の全3ファイルに同一パターンを一括投入 |
| Item | Detail |
|---|---|
| Commit | 2407d2f556c7 |
| Author | Zhuoran Yin (zhuoryin@amd.com) — AMD employee |
| Date | 2021-12-22 |
| PR | MIOpen #1328: "[MLIR] Disable gfx900 from non-xdlops solver" |
| Referenced issue | ROCm/llvm-project-private/issues/389 — AMD internal private repo |
| Scope | Same exclusion pattern applied to all 3 files (fwd / bwd / wrw) |
IsMlirSupportedHardware() には gfx900 が「対応ハード」として gfx906/908/90a/942 と並列にリストされている。しかし ConvMlirIgemmFwd::IsApplicable() が個別に gfx900 を除外している。つまり「MLIR 対応と表明しつつ、特定アーチで例外除外」という二層構造であり、設計意図としての残存と個別バグ回避が共存している。
Structural note: IsMlirSupportedHardware() lists gfx900 alongside gfx906/908/90a/942 as "supported hardware". Yet ConvMlirIgemmFwd::IsApplicable() individually excludes gfx900. This two-layer structure — declaring support while making architecture-specific exceptions — indicates coexistence of design-level inclusion and individual bug workarounds.
"Disable" の語感はバグ回避寄りだが、private issue の本文が非公開のため設計判断かバグ回避かの確定はできない。さらに 2026-03-14 の強制実行追試では、-S により IsApplicable() をバイパスすると CompileSolution → GetInvoker まで進み、Perf Db: record not found → boost::optional::get() assert に落ちることも確認された。したがって、現時点で確定しているのは「後段経路のどこかが未整備である」ことであり、単一原因を LLVM バックエンドだけに還元することはできない。
The word "Disable" suggests a bug workaround, but the private issue body is inaccessible, so whether this was a design decision or bug avoidance cannot be confirmed. A 2026-03-14 forced-run follow-up also showed that once -S bypasses IsApplicable(), execution can reach CompileSolution → GetInvoker and then fail with Perf Db: record not found → boost::optional::get() assertion. What is firmly established is therefore that some downstream path remains incomplete; the public evidence does not justify reducing everything to the LLVM backend alone.
追補（2026-03-15）: MiirIsConfigApplicable() の先にある Miir 実装は public な ROCm/rocMLIR（rocmlir-lib.cpp）で追跡可能。miirLowerTuningParams() は Applicability モードで pipeline を実行し、失敗時に MIIR_BUILD_FAILURE を返す。よって未解決なのは Miir 実装の不可視性ではなく、private issue #389 が示す 2021 年当時の判断根拠である。
Addendum (2026-03-15): The Miir implementation behind MiirIsConfigApplicable() is publicly traceable in ROCm/rocMLIR (rocmlir-lib.cpp). miirLowerTuningParams() runs the pipeline in applicability mode and returns MIIR_BUILD_FAILURE on failure. Therefore, the unresolved part is no longer Miir visibility itself, but the 2021 decision context hidden behind private issue #389.
IsMlirSupportedHardware リストへの gfx900 残存は「設計意図としてのサポート表明」であり、solver レベルの skip は別レイヤの問題IsMlirSupportedHardware constitutes a design-level support declaration; solver-level skip is a separate-layer concernVega/gfx900 は「完全非対応」というより、「主要サポート対象から外れたが、なお複数の実行経路とフォールバック経路が残っている世代」と捉えるのが適切である。
Vega/gfx900 is better understood as deprecated rather than strictly non-functional: while no longer positioned as a primary support target, multiple execution and fallback paths remain present in the ROCm software stack.
| 問い | 現在の答え | 確度 |
|---|---|---|
| gfx900 の経路はコードに残っているか | 残っている | code_verified |
| それは設計上自然に残っているか | そう読める | hypothesis + code evidence |
| 主要分岐の投入主体は誰か | 少なくとも一部は AMD 側。MLIR gfx900 除外は AMD 社員 commit | history_verified |
| 維持主体は誰か | 未確定。積極維持・削除コスト由来残存・部分的コミュニティ支援の寄与は未分離 | hypothesis |
| 運用主体は誰か | コミュニティが発見・運用・回避策共有を担う可能性が高い | hypothesis |
| 修正可能主体は誰か | 層ごとに異なる。userspace は外部修正余地があり、backend 根本対応は到達困難な可能性 | hypothesis |
| MLIR iGEMM 除外の投入者は誰か | AMD 社員 Zhuoran Yin | code_verified |
| MLIR 除外の根拠 issue は公開か | 非公開（llvm-project-private） | code_verified |
| 除外の性質（設計判断 vs バグ回避） | "Disable" はバグ回避寄り。確定不可 | hypothesis |
| 経路はコミュニティ実装で維持されているか | 部分的に Yes。MLIR 除外は AMD 投入だが、Tensile の gfx900 残存性は外部 contributor PR（#1595/#1862）で補修 | history_verified |
| 実際に実機で選ばれているか | FP32 solver 選択は確認済み | runtime_verified |
| UDNA / 再統合との関係 | 意図は未確定、構造は観測できる | speculative |
| Question | Current answer | Confidence |
|---|---|---|
| Do gfx900 execution paths remain in code? | Yes | code_verified |
| Are they a natural consequence of design? | Consistent reading | hypothesis + code evidence |
| Who owns key insertion points? | At least some are AMD-side. The MLIR gfx900 exclusion is an AMD employee commit | history_verified |
| Who owns long-term maintenance? | Unresolved. Active maintenance, deletion-cost survival, and partial community support are not yet separated | hypothesis |
| Who owns operation in practice? | The community likely carries discovery, operation, and workaround sharing | hypothesis |
| Who can realistically repair issues? | Depends on the layer: some userspace issues are reachable, backend root fixes may not be | hypothesis |
| Who introduced MLIR iGEMM exclusion? | Zhuoran Yin (AMD) | code_verified |
| Is the root issue public? | No (llvm-project-private) | code_verified |
| Nature of exclusion (design vs bug workaround)? | "Disable" leans bug-workaround. Cannot confirm | hypothesis |
| Are paths community-maintained? | Partially yes. MLIR exclusion is AMD-authored, while Tensile gfx900 survivability was reinforced by external-contributor PRs (#1595/#1862) | history_verified |
| Actually selected at runtime? | FP32 solver selection confirmed | runtime_verified |
| Relation to UDNA / re-integration? | Intent undetermined; structure observable | speculative |
以下は調査過程で生じたブレインストーミング・仮説形成・各種コメントの記録である。これは陰謀論ではなく、工学的問いの思考過程であり、調査によってどのように解消・修正されていったかを含めて記載する。結論から読みたい方は §1–§6 のみで十分である。
Below is a record of brainstorming, hypothesis formation, and review comments generated during the investigation. This is not conspiracy theorizing — it is the thinking process behind an engineering question, including how ideas were resolved or corrected through investigation. Readers interested only in conclusions may skip to §1–§6.
出発点は素朴な疑問だった:
Vega/gfx900 はなぜ今も生きているのか。それは情けで放置されているのか、設計上自然に残っているのか。
この問いには暗黙の前提がある。「サポート終了 = 動かなくなる」という思い込みである。この前提自体を疑うところから調査は始まった。結果として、「動く」と「サポートされている」の間には広いグレーゾーンがあることが判明し、仮説 A（表のサポートと設計上のサポートは別）が生まれた。
The starting point was a naive question:
Why does Vega/gfx900 still work? Is it neglected out of mercy, or naturally preserved by design?
This question contained an implicit assumption: "end of support = stops working". Questioning this assumption was the beginning of the investigation. The result was the discovery of a wide gray zone between "functional" and "supported", which led to Hypothesis A (official support and design-level support are distinct).
段階 1: 「延命されている」仮説
最初は「誰かが gfx900 を特別扱いで延命しているのでは」と考えた。しかしコード調査の結果、dot4 不在時のフォールバックが gfx900 専用ではなく汎用設計であることが判明し、この仮説は棄却された。
段階 2: 「設計の副産物」仮説
MIOpen の solver finder が候補列挙 + IsApplicable フィルタ方式であることを確認した時点で、仮説 B（capability-based 設計の自然な帰結）が形成された。これは最も強いコード根拠を持つ仮説として現在も維持されている。
段階 3: 「UDNA への布石」仮説
rDNA/cDNA 分離と UDNA 統合方向の話が出た時点で、仮説 D（繋ぎとしての分離）が生まれた。しかし議論と調査を深める過程で「UDNA というゴールが見えている今だからそう見えているだけで、証拠を積む前に語りすぎるとロマンで終わる」という批判を受け、仮説 E（意図は未確定、構造は観測できる）に着地した。
段階 4: 「第三の可能性」の発見
「設計の自然な帰結 vs コミュニティの保守」の二項対立で考えていたが、議論の中で「AMD が積極的に消していない」という第三の状態の存在を指摘された。これはコスト-便益的な判断によるものであり、より地に足のついた説明として有力。
Stage 1: "Life support" hypothesis
Initially, the assumption was that someone was giving gfx900 special treatment. Code investigation revealed that the dot4 fallback is generic, not gfx900-specific, and this hypothesis was rejected.
Stage 2: "Design byproduct" hypothesis
After confirming MIOpen's solver finder uses candidate enumeration + IsApplicable filtering, Hypothesis B (natural consequence of capability-based design) was formed. This remains the hypothesis with the strongest code evidence.
Stage 3: "UDNA foresight" hypothesis
The rDNA/cDNA split combined with UDNA unification signals gave rise to Hypothesis D (split as transitional). Peer review criticism — "it only looks that way because UDNA is now visible; without evidence this is just romance" — led to the more conservative Hypothesis E (intent undetermined, structure observable).
Stage 4: Discovery of the "third possibility"
The binary framing of "design consequence vs community maintenance" was challenged by peer review, which identified a third state: "AMD hasn't actively removed it". This cost-benefit explanation is potentially the most grounded.
solver の静的コード調査だけでは不十分と考え、Vega 64 実機上で solver を強制実行する検証に移った。ここで想定外の現象が次々と発生した:
ConvMlirIgemmFwd 強制実行 → MIIR_INVALID_PARAM / rc=0x7ConvCkIgemmFwdV6r1DlopsNchw 7ケース → 全件 not applicable / rc=0x3-s 1 + C/K 極値 + stride 差 + NHWC/NCHW の8ケース → 同じく全件 not applicableConvHipImplicitGemmFwdXdlops → CompileSolution/GetInvoker まで進むが assertion abort (EXIT=134)ConvHipImplicitGemmForwardV4R5Xdlops → xdlops kernel compile 失敗（intrin_mfma_* 不在）この経験から得られた教訓: DLOPS/XDLOPS 系は「候補名が存在する」ことと「当該 problem で成立する」ことが完全に分離している。solver family ごとに「到達点（applicability 判定の前後）」が異なるため、失敗モード分類（§2）の枠組みが生まれた。
さらに 2026-03-14 の追試では、ConvMlirIgemmFwd 強制実行が CompileSolution / GetInvoker まで進み、Perf Db: record not found → boost::optional::get() assert に落ちることも確認した。つまり強制実行は通常ガードの外側にある未整備な downstream path を露出させる。
Static code analysis alone was deemed insufficient, so runtime solver forcing on Vega 64 was attempted. Unexpected failures emerged in sequence:
ConvMlirIgemmFwd forced → MIIR_INVALID_PARAM / rc=0x7ConvCkIgemmFwdV6r1DlopsNchw in 7 configs → all not applicable / rc=0x3-s 1 + extreme C/K + stride variations + NHWC/NCHW (8 cases) → all not applicableConvHipImplicitGemmFwdXdlops → reached CompileSolution/GetInvoker but assertion abort (EXIT=134)ConvHipImplicitGemmForwardV4R5Xdlops → xdlops kernel compile failure (missing intrin_mfma_*)Key lesson: "Solver name exists" and "solver applies to a given problem" are completely separate. Each solver family fails at a different stage, leading to the failure mode taxonomy in §2.
A 2026-03-14 follow-up further showed that forced ConvMlirIgemmFwd can reach CompileSolution / GetInvoker and then die at Perf Db: record not found → boost::optional::get(). Forced execution therefore exposes unfinished downstream paths outside the normal guard.
最も評価された点:
dot4 不在フォールバックは gfx900 専用ではなく、capability が立たない世代全般向けの汎用レイヤ」という観察 → capability-based 設計の証拠として最も強い慎重にすべきと指摘された点:
新たな視点:
Most positively received:
dot4 fallback is not gfx900-specific but a generic layer for any generation without the capability" → strongest evidence for capability-based designFlagged for caution:
New perspectives added:
動的失敗シグネチャを読むための静的結線の基準点を以下に固定した:
solver.cpp: solver 登録点fin_interface.cpp: 強制指定 ID（80/114/128）mlir_build.cpp: MIIR_INVALID_PARAM 変換点hipoc_program.cpp: .mlir 分岐と Code object build failed throw 点これにより、前節の動的失敗シグネチャを3層（applicability reject / build 失敗 / runtime abort）に分けて読む前提が整った。
Static trace baseline was established to interpret dynamic failure signatures:
solver.cpp: solver registration pointfin_interface.cpp: forced solver IDs (80/114/128)mlir_build.cpp: MIIR_INVALID_PARAM translation pointhipoc_program.cpp: .mlir branch and Code object build failed throw pointThis allowed the dynamic failure signatures to be read across three layers: applicability reject / build failure / runtime abort.
MiirIsConfigApplicable の実装到達（public ROCm/rocMLIR）: miirLowerTuningParams は Applicability pipeline 実行、失敗時 MIIR_BUILD_FAILUREMiirIsConfigApplicable (public ROCm/rocMLIR): miirLowerTuningParams runs applicability pipeline and returns MIIR_BUILD_FAILURE on failureConvBinWinograd3x3U / ConvAsm1x1U / ConvHipImplicitGemmV4R1Fwd を自然選択で確認）ConvBinWinograd3x3U / ConvAsm1x1U / ConvHipImplicitGemmV4R1Fwd)v_dot4_* の有無確認手順の確立v_dot4_* presence verification procedure established2407d2f、PR #1328）2407d2f, PR #1328)#389 の参照先が llvm-project-private（AMD private）であることを確定#389 references llvm-project-private (AMD private repository)llvm-project で gfx900 / MLIR 関連の commit / issue を再探索llvm-project for gfx900 / MLIR related commits and issuesMIIR_BUILD_FAILURE を誘発する最小再現ケースを抽出し、MIOpen 側の失敗シグネチャ（rc=0x7）と対応づけるMIIR_BUILD_FAILURE and map it to MIOpen failure signatures (rc=0x7)ConvDirectNaiveConvFwd のみ）ConvDirectNaiveConvFwd only)