RVCC 想加速 RISC-V 調校，LLVM 先打槍

RISC-V 的編譯器調校，現在不是玩票。LLVM 社群正在討論一個叫 RVCC 的孵化器提案。目標很直接：把 RISC-V 的最佳化 patch 集中處理，讓測試和迭代跑更快。

這件事會吵起來，不意外。因為 Clang 和 LLVM 的流程本來就很嚴。你想快一點，maintainer 就會問：那品質誰扛？

更有意思的是，RISC-V 已經不是小眾圈內話題。它開始進伺服器、嵌入式和開發板。講白了，編譯器好不好，會直接影響產品選型和效能表現。

RVCC 到底想解什麼問題

RVCC 的核心想法很簡單。不要讓每個 RISC-V patch 一開始就擠進 LLVM 主流程。先放到一個共享空間裡，先跑 benchmark，再把表現好的改動往上送。

這種做法的吸引力很實際。RISC-V 的優化工作，常常卡在 review 速度。不同公司、不同板子、不同微架構，都在試自己的調法。結果就是大家都在重複踩坑。

如果有一個共同場域，至少可以少一點各自為政。對做工具鏈的人來說，這比單打獨鬥省事很多。對上游來說，也可能少收一些品質不穩的 patch。

• 聚焦 RISC-V 的 LLVM 與 Clang 最佳化
• 先用 benchmark 驗證，再決定是否上游
• 降低各家私有 toolchain 分支的分裂風險
• 讓 patch 先在共享空間成熟再送審

這個概念很像 Linux kernel 的 staging 區。差別在於，這裡處理的是編譯器，不是 driver。編譯器的副作用更難抓，因為你改一行，可能整個 codegen 都變。

所以 RVCC 不是單純要「讓大家快點送 patch」。它其實是在問：能不能先把實驗和正式審查拆開，讓 RISC-V 的調校更有效率。

LLVM 為什麼先反對

問題來了。LLVM maintainer Nikita Popov 在 LLVM Discourse 上直接回了強烈反對。他的意思很直白：這看起來像一個 LLVM fork，再加上一些不符合 LLVM 標準的 patch。

“This proposal gets a strong no from me. We should not have an incubator for what is basically an LLVM fork plus patches that fail to meet LLVM’s usual quality standards.” — Nikita Popov

這句話很重，但也很 LLVM。這個專案一直靠嚴格審查維持一致性。你一旦開一個比較鬆的入口，maintainer 很自然會擔心，最後是不是要幫別人的技術債收尾。

還有一個更現實的問題。若 RVCC 變成 RISC-V patch 的預設入口，大家會不會開始把它當成「夠用就好」的第二管道？那樣一來，主線 LLVM 的門檻就會被間接稀釋。

我覺得這才是爭點核心。不是要不要加速，而是加速的方法，會不會把 LLVM 的治理模型弄鬆。

這跟其他編譯器流程差在哪

編譯器專案本來就有不同的工作流。只是每種方法，代價都不一樣。LLVM 的主線 review 很嚴，優點是穩，缺點是慢。

RISC-V 的情況又更複雜。RISC-V International 的生態很雜，從新創晶片商到學界原型都有。你在一顆核心上跑得漂亮，不代表別顆也會買單。

所以 benchmark 不是裝飾品，是必要條件。尤其是 RISC-V 這種實作差異大的架構，光看單一機器的結果，常常會誤判。

• LLVM：集中審查，品質一致，但速度較慢
• RVCC 提案：先孵化再上游，迭代快，但容易分岔
• Linux kernel staging：先成熟再進主線，是可參考的模式
• RISC-V International：硬體差異大，測試條件更難統一

再看競品或替代路線，事情就更清楚。GCC 也有自己的 RISC-V backend 調校節奏。各家晶片商若覺得上游太慢，通常就會先在私有分支修。問題是，私有分支越多，最後越難對齊。

RVCC 若真要成立，至少要回答三個問題：誰決定收 patch、怎麼量化效能、怎麼保證最後會回到主線。少一個，這東西就很像半個實驗室，半個 fork。

RISC-V 的工具鏈壓力從哪來

RISC-V 這幾年受關注，不是因為口號，而是因為實際部署開始變多。從低功耗裝置到伺服器，大家都在看它能不能省成本、保彈性、保供應鏈。

但硬體一旦多樣化，編譯器壓力就上來。你不能只看 ISA 規格。你還要看 pipeline、快取、分支預測、記憶體延遲，甚至是廠商自己加的擴充。

這也是為什麼 RISC-V 的效能優化特別吃人力。不是寫一個演算法就結束。你得在不同板子上反覆驗證，還要知道哪些變動是局部有效，哪些是全域有效。

產業脈絡也很直接。過去幾年，很多團隊先做原型，再慢慢拉上游。現在情況變了。當晶片真的要出貨，toolchain 的成熟度就不能只靠「差不多能跑」。

我會說，RVCC 的出現本身就說明一件事：RISC-V 的競爭，已經從硬體規格表，轉到編譯器和工具鏈的細節戰了。

接下來會怎麼走

目前 RVCC 還只是提案，不是正式項目。接下來要看的，不是誰聲音大，而是誰能拿出可驗證的流程。

我猜 LLVM 不太可能接受一個看起來像 soft fork 的設計。比較可能的版本，是一個更窄的合作空間。規則要更硬，benchmark 方法要更透明，回主線的路也要更短。

如果這案子真的要活下來，它必須證明自己是在幫 LLVM 篩 patch，不是在幫人繞過 LLVM。這條線很細，但很重要。

對台灣開發者來說，這件事也不算遠。只要你碰到 RISC-V 開發板、嵌入式軟體，或自己編譯 toolchain，這場爭論最後都會回到你手上。因為編譯器怎麼長，會直接影響你拿到的效能和除錯成本。

如果你想跟進這條線，建議順手看 LLVM 的 release 節奏，以及 Discourse 上的 RISC-V 討論。接下來 6 到 12 個月，這類工具鏈治理問題只會更常見，不會更少。