論文の概要: An Executable Benchmark for LLM-Based HLS Repair:Design Complexity and Repair Underconstraint

• arxiv url: http://arxiv.org/abs/2610.03971v1
• Date: Fri, 02 Oct 2026 19:28:05 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-10-12 21:18:03.905771
• Title: An Executable Benchmark for LLM-Based HLS Repair:Design Complexity and Repair Underconstraint
• Title（参考訳）: LLMによるHLS修復のための実行可能ベンチマーク:設計複雑度と修復下制約
• Abstract要約: 大規模言語モデル(LLM)を用いた高レベル合成(HLS)設計の自動修復の総合的評価について述べる。 我々は,APRスタイルのHLS修復ベンチマークを,スイート固有の機能オラクルを用いて構築する。 修復率は、複雑な暗号カーネルの6-45%から、コンパクトなアルゴリズムカーネルの81-93%まで様々である。
• 参考スコア（独自算出の注目度）: 0.8450904497835263
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: Automated repair of High-Level Synthesis (HLS) designs using large language models (LLMs) is an emerging but underexplored problem. While LLM-based repair shows strong results on register-transfer level (RTL) Verilog, the only prior systematic study of HLS logic repair reports just 10.5% correction accuracy for GPT-4, with no analysis of why repair fails or what drives difficulty. We present the first comprehensive evaluation of LLM-based HLS repair across four models (GPT-4o, GPT-4o-mini, GPT-5.4, and Claude Opus 4.6) on 125 benchmark instances spanning eight logic bug types across three open-source HLS suites (CHStone, MachSuite, Polybench). We construct the first executable APR-style HLS repair benchmark with suite-specific functional oracles, enabling pass@k evaluation rather than the string-match approximations used in prior work. Design context and scale, rather than bug type alone, dominate repair difficulty: repair rates range from 6-45% on complex cryptographic kernels (CHStone) to 81-93% on compact algorithmic kernels (MachSuite) despite identical bug type distributions. We introduce solution multiplicity, the fraction of distinct patches generated across repeated repair attempts, as an empirical measure of repair underconstraint, and show it strongly predicts repair failure across all four models (Spearman rho = -0.393, p = 6.61 x 10^-20). Frontier models reduce underconstrained instances from 41-46 (GPT-4o, GPT-4o-mini) to just 3 (Claude Opus 4.6), with pass@1 improving from 42-53% to 73-76%. SHFT bugs remain consistently hard across all models, and semantic bug classes such as buffer indexing become reliably repairable only at frontier scale. These findings show that future APR benchmarks must include complex, executable, and weakly identifiable designs that remain challenging after frontier LLM repair.
• Abstract（参考訳）: 大規模言語モデル(LLM)を用いた高レベル合成(HLS)設計の自動修復は、新しいが未発見の課題である。 LLMベースの修復はレジスタ・トランスファー・レベル(RTL)のVerilogに強い結果を示すが、HLS論理修復の体系的な研究はGPT-4の修正精度を10.5%しか報告していない。 GPT-4o, GPT-4o-mini, GPT-5.4, Claude Opus 4.6) を,オープンソースの3つの HLS スイート (CHStone, MachSuite, Polybench) にまたがる8つの論理バグタイプにまたがる125のベンチマークインスタンス上で, LLM ベースの HLS 修復の総合的な評価を行った。 本研究では,APRスタイルのHLS修復ベンチマークを,スイート固有の機能オーラクルを用いて構築し,前処理で使用する文字列マッチ近似よりもpass@k評価を実現する。 修復率は、複雑な暗号カーネル(CHStone)の6-45%から、同じバグタイプのディストリビューションにもかかわらず、コンパクトなアルゴリズムカーネル(MachSuite)の81-93%まで様々である。 本研究では, 繰り返し補修試験において発生する個々のパッチの差分である解乗法を導入し, 補修過小制約を実験的に評価し, 補修失敗を4モデルすべてにわたって強く予測することを示した(Spearman rho = -0.393, p = 6.61 x 10^-20)。 Frontierモデルは制約の少ないインスタンスを41-46(GPT-4o, GPT-4o-mini)から3つ(Claude Opus 4.6)に減らし、pass@1は42-53%から73-76%に改善した。 SHFTバグは、すべてのモデルで一貫してハードであり、バッファインデックスのようなセマンティックバグクラスは、フロンティアスケールでのみ確実に修復可能である。 これらの結果は、将来のAPRベンチマークには、フロンティアLSM修復後も困難なままである複雑な、実行可能、そして弱い識別可能な設計を含めなければならないことを示している。

関連論文リスト

• Harnessing LLMs for Reliable Academic Supervision: A Comparative Study [0.0]
  大規模言語モデルは、単発プロンプトに対する流動的な回答を日常的に生成するが、それらをドメイン決定システムの信頼性の高いコンポーネントとしてデプロイするのは、かなり難しい。 このギャップを埋めるのは、決定論的足場を意図的に構成する、ハーネスエンジニアリングの作業である。 本稿では,高評価,経時的アカウンタビリティ,構造化された運用研究を併用した,学術的監督の事例を紹介する。
  論文  参考訳（メタデータ） (2026-07-16T08:14:27Z)
• A Metamorphic Testing Approach to Diagnosing Memorization in LLM-Based Program Repair [9.198826017433388]
  大規模言語モデル(LLM)は、評価ベンチマークが事前トレーニングデータと重なり合うとバグ修正を記憶し、パフォーマンスの見積もりが膨らむ。 メタモルフィックテスト (MT) と負の対数類似度 (NLL) を組み合わせることにより, データの漏洩を明らかにすることができるかを検討する。 以上の結果から,GPT-4oでは4.1%,Llama-3.1では15.98%と,パッチ生成率の大幅な低下が認められた。
  論文  参考訳（メタデータ） (2026-04-23T11:59:53Z)
• Specification-Guided Repair of Arithmetic Errors in Dafny Programs using LLMs [79.74676890436174]
  本稿では,障害の局所化と修復のためのオラクルとして形式仕様を用いたDafny用のAPRツールを提案する。 プログラム内の各ステートメントの状態を決定するために、Hoareロジックの使用を含む一連のステップを通じて、障害をローカライズします。 また, GPT-4o miniが74.18%と高い修理成功率を示した。
  論文  参考訳（メタデータ） (2025-07-04T15:36:12Z)
• Enhancing repository-level software repair via repository-aware knowledge graphs [13.747293341707563]
  リポジトリレベルのソフトウェア修復は、問題記述とコードパッチの間のセマンティックギャップを埋める際の課題に直面します。 既存のアプローチは、大きな言語モデル(LLM)に依存しており、意味的曖昧さ、構造的文脈の限られた理解、推論能力の不足によって妨げられている。 本稿では,リポジトリアーティファクト(課題とプル要求)とエンティティ(ファイル,クラス,関数)を正確にリンクする新しいリポジトリ対応知識グラフ(KG)を提案する。 KGをマイニングした経路を利用する経路誘導補修機構により,説明とともに文脈情報を拡張することができる。
  論文  参考訳（メタデータ） (2025-03-27T17:21:47Z)
• See What LLMs Cannot Answer: A Self-Challenge Framework for Uncovering LLM Weaknesses [51.975495361024606]
  本稿では,Human-in-the-loopを用いたセルフチェレンジ評価フレームワークを提案する。 GPT-4が答えられないシードインスタンスから始めて、GPT-4に新しいインスタンスを生成するのに使えるエラーパターンを要約するように促します。 次に,GPT-4が生成する1,835個のインスタンスと,人手によるゴールド応答を併用したベンチマーク,SC-G4を構築した。
  論文  参考訳（メタデータ） (2024-08-16T19:01:52Z)
• Is Self-Repair a Silver Bullet for Code Generation? [68.02601393906083]
  大規模な言語モデルは、コード生成において顕著な適性を示しているが、それでも複雑なタスクを実行するのに苦労している。 自己修復(Self-repair) — モデルが自身のコードをデバッグし、修復する — は、最近、パフォーマンスを向上する一般的な方法になっている。 我々は,Code Llama, GPT-3.5, GPT-4によるHumanEvalとAPPSの自己修復能力について分析した。
  論文  参考訳（メタデータ） (2023-06-16T15:13:17Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。