、優(yōu)化Pass與llvmpipe軟件渲染實(shí)戰(zhàn))
1. LLVM到底是個(gè)什么項(xiàng)目從一次排查渲染問(wèn)題說(shuō)起前陣子有同事給我發(fā)來(lái)一條日志上面寫(xiě)著llvmpipe (LLVM 15.0.7, 256 bits)問(wèn)我這行字是什么意思是不是系統(tǒng)出了故障。我一看就樂(lè)了——這哪是故障這是你的軟件渲染器在老實(shí)交代自己的“底牌”。llvmpipe是 Mesa 圖形棧里的 CPU 軟件渲染實(shí)現(xiàn)它背后站著的是 LLVM 這個(gè)編譯器基礎(chǔ)設(shè)施。如果只看名字很多人以為 llvmpipe 是某種管道工具其實(shí)它的意思是“用 LLVM 實(shí)現(xiàn)的軟件像素管線”。說(shuō)到 LLVM很多人第一反應(yīng)是“哦Clang 編譯器”。這個(gè)理解沒(méi)錯(cuò)但太窄了。LLVM 是一個(gè)龐大的編譯器基礎(chǔ)設(shè)施項(xiàng)目Clang 只是它上面的一個(gè)前端。從手機(jī) App 到游戲引擎從 GPU 驅(qū)動(dòng)到編程語(yǔ)言工具鏈背后都有 LLVM 的身影。我自己最早接觸 LLVM 是為了搞清楚編譯器優(yōu)化到底在優(yōu)化什么結(jié)果一頭扎進(jìn)去就再?zèng)]出來(lái)——這個(gè)項(xiàng)目的設(shè)計(jì)思路、工程組織、社區(qū)文化在開(kāi)源世界里幾乎找不到第二個(gè)同級(jí)別的存在。這篇文章我想從一個(gè)軟件渲染日志中的256 bits說(shuō)起把 LLVM 項(xiàng)目的整體結(jié)構(gòu)、核心設(shè)計(jì)、實(shí)際操作和避坑經(jīng)驗(yàn)一次講清楚。不管你是做編譯器開(kāi)發(fā)的、寫(xiě) GPU 驅(qū)動(dòng)的、還是單純想搞懂“編譯器是怎么工作的”這篇文章應(yīng)該都能給你一些參考。2. 三段式架構(gòu)為什么 LLVM 能“一招鮮吃遍天”2.1 從“翻譯官”到“萬(wàn)能中間層”傳統(tǒng)編譯器的結(jié)構(gòu)是“前端 后端”前端解析源代碼生成中間表示后端把中間表示翻譯成目標(biāo)機(jī)器碼。問(wèn)題在于前端和后端是一一綁定的來(lái)一個(gè)新語(yǔ)言就要寫(xiě)一套完整工具鏈來(lái)一個(gè)新 CPU 架構(gòu)又要重寫(xiě)一遍后端。這種模式的維護(hù)成本極高而且優(yōu)化邏輯分散在前后端里很難統(tǒng)一復(fù)用。LLVM 的設(shè)計(jì)思路從根本上改變了這個(gè)局面。它把編譯器拆成了三段前端Frontend、中端優(yōu)化器Optimizer、后端Backend。前端把源代碼翻譯成 LLVM IR這是一個(gè)獨(dú)立于具體語(yǔ)言和具體硬件的中間表示中端優(yōu)化器針對(duì) IR 做各種通用的優(yōu)化后端再把優(yōu)化后的 IR 翻譯成目標(biāo)平臺(tái)的機(jī)器碼。我習(xí)慣用一個(gè)翻譯公司的例子來(lái)解釋前端是“中文翻譯成世界語(yǔ)”的譯員中端是“把世界語(yǔ)文本潤(rùn)色改稿”的編輯后端是“把世界語(yǔ)翻譯成英文、日文、法文”的另一批譯員。世界語(yǔ)就是 LLVM IR它本身不是最終產(chǎn)物但它讓整個(gè)流程可以靈活組合——來(lái)一門(mén)新語(yǔ)言只需要新招一個(gè)“中文翻譯成世界語(yǔ)”的譯員其他環(huán)節(jié)全部復(fù)用。這個(gè)設(shè)計(jì)的威力在哪兒一個(gè)編程語(yǔ)言社區(qū)想做自己的編譯器只要寫(xiě)一個(gè)前端生成 LLVM IR就能立刻獲得全套優(yōu)化、調(diào)試、代碼生成能力。一個(gè)芯片廠商想支持新指令集只要寫(xiě)好 LLVM 后端所有基于 LLVM 的語(yǔ)言都能跑上新硬件。這就是 LLVM 能成為“編譯器領(lǐng)域的 Linux”的根本原因。2.2 IR 的三層表示為什么調(diào)試信息能跨越整個(gè)編譯流程LLVM IR 不是一個(gè)單一的形態(tài)它有三層表示內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)、文本形式的.ll文件、二進(jìn)制形式的.bc文件。這聽(tīng)起來(lái)像純工程實(shí)現(xiàn)細(xì)節(jié)但它對(duì)實(shí)際開(kāi)發(fā)的影響非常大。文本形式.ll是可讀的方便調(diào)試和分析優(yōu)化過(guò)程。我在寫(xiě) Pass 的時(shí)候經(jīng)常把 IR 打印出來(lái)逐條檢查優(yōu)化前后的差異。二進(jìn)制形式.bc適合存儲(chǔ)和快速加載常用于鏈接時(shí)優(yōu)化的場(chǎng)景。內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)則是編譯器運(yùn)行時(shí)的真實(shí)狀態(tài)。更關(guān)鍵的是IR 從生成到變成機(jī)器碼一直保留著源代碼層面的元數(shù)據(jù)。變量名、文件路徑、行號(hào)、類型信息都掛在 IR 的指令和函數(shù)上。這意味著你在調(diào)試優(yōu)化后的代碼時(shí)還能把機(jī)器碼準(zhǔn)確地映射回源代碼——這個(gè)能力叫 DWARF 調(diào)試信息它讓 GDB、LLDB 等調(diào)試器能正常工作。沒(méi)有這個(gè)設(shè)計(jì)編譯器優(yōu)化做得再漂亮調(diào)試體驗(yàn)也會(huì)一團(tuán)糟。2.3 項(xiàng)目倉(cāng)庫(kù)里到底裝了什么一次目錄掃盲很多初學(xué)者 clone 下 llvm-project 倉(cāng)庫(kù)之后看著根目錄下那一大堆文件夾直接懵了。我來(lái)幫你掃一遍最重要的目錄llvm/核心目錄包含 LLVM 的基礎(chǔ)庫(kù)、優(yōu)化器、后端、IR 定義、工具鏈。clang/C/C/Objective-C 的前端這是 LLVM 最重要的前端實(shí)現(xiàn)。lld/高性能鏈接器鏈接速度比 GNU ld 快很多我自己實(shí)測(cè)大項(xiàng)目鏈接能快兩三倍。compiler-rt/運(yùn)行時(shí)庫(kù)提供諸如地址消毒器ASan、未定義行為消毒器UBSan等工具的支持。libcxx/和libcxxabi/C 標(biāo)準(zhǔn)庫(kù)和 ABI 庫(kù)的實(shí)現(xiàn)。flang/Fortran 語(yǔ)言前端科研和 HPC 領(lǐng)域用得比較多。mlir/MLIR 項(xiàng)目專門(mén)為機(jī)器學(xué)習(xí)編譯器設(shè)計(jì)的多層中間表示框架現(xiàn)在已經(jīng)是 AI 編譯器的核心基礎(chǔ)設(shè)施。polly/基于多面體模型的循環(huán)優(yōu)化框架偏學(xué)術(shù)研究方向。clang-tools-extra/各種 Clang 輔助工具比如 clang-tidy、clang-format。這套結(jié)構(gòu)體現(xiàn)了 LLVM 的設(shè)計(jì)哲學(xué)每個(gè)子項(xiàng)目都是獨(dú)立可用的組件組合在一起又是一個(gè)完整的工具鏈。你可以只拿 clang-format 這個(gè)工具來(lái)規(guī)范代碼風(fēng)格也可以把整個(gè) LLVM 作為依賴集成進(jìn)自己的產(chǎn)品里。3. 核心組件與構(gòu)建系統(tǒng)先把工程踩熟3.1 CMake 配置決定你接下來(lái)幾個(gè)小時(shí)命運(yùn)的參數(shù)LLVM 使用 CMake 作為構(gòu)建系統(tǒng)。這不是簡(jiǎn)單的“運(yùn)行 cmake 然后 make”的問(wèn)題幾個(gè)關(guān)鍵參數(shù)的選擇直接決定構(gòu)建耗時(shí)和最終產(chǎn)物質(zhì)量。我把自己常用的參數(shù)整理成一個(gè)表參數(shù)推薦值作用與理由LLVM_ENABLE_PROJECTSclang;lld指定額外構(gòu)建的子項(xiàng)目用分號(hào)分隔構(gòu)建順序有依賴關(guān)系LLVM_TARGETS_TO_BUILDX86只構(gòu)建需要的目標(biāo)架構(gòu)后端全量構(gòu)建會(huì)消耗大量時(shí)間和磁盤(pán)CMAKE_BUILD_TYPERelease或RelWithDebInfoRelease 性能好RelWithDebInfo 保留調(diào)試信息調(diào)試用后者LLVM_USE_LINKERlld或gold鏈接器選擇大項(xiàng)目鏈接時(shí) lld 能省大量時(shí)間LLVM_PARALLEL_LINK_JOBS2或4限制并行鏈接任務(wù)數(shù)防止鏈接階段內(nèi)存爆掉LLVM_ENABLE_ASSERTIONSON開(kāi)發(fā)時(shí)開(kāi)啟斷言能幫你早期發(fā)現(xiàn)問(wèn)題但會(huì)拖慢性能我踩過(guò)最大的坑就是第一次構(gòu)建時(shí)沒(méi)設(shè)置LLVM_TARGETS_TO_BUILD結(jié)果全量構(gòu)建了所有后端包括我根本用不到的 AArch64、PowerPC、MIPS磁盤(pán)直接被吃掉幾十 GB。第二次學(xué)乖了只保留 X86構(gòu)建時(shí)間縮短了一半以上。3.2 構(gòu)建機(jī)器的最低配置與時(shí)間預(yù)期LLVM 構(gòu)建是 CPU 密集型的活兒建議至少 8 核 16 線程以上的機(jī)器。16 GB 內(nèi)存是底線如果你開(kāi)啟了并行鏈接建議 32 GB。磁盤(pán)方面光源碼就得 1-2 GB構(gòu)建產(chǎn)物按配置不同要 20-50 GB。如果你打算用ccache做增量編譯緩存那再加 20 GB 也不嫌多。構(gòu)建時(shí)間因機(jī)器而異。一臺(tái) 16 核的現(xiàn)代機(jī)器全量構(gòu)建 LLVM Clang lld 的 Release 版本大概需要 30-60 分鐘。配置越全、調(diào)試信息越多時(shí)間越長(zhǎng)。我試過(guò)在一臺(tái) 4 核老機(jī)器上構(gòu)建整整跑了三個(gè)多小時(shí)中途還因?yàn)閮?nèi)存不夠崩了兩次。所以如果你只是學(xué)習(xí)用建議先只構(gòu)建llvm本體的工具鏈沒(méi)必要一上來(lái)就全量構(gòu)建所有子項(xiàng)目。3.3 從源碼構(gòu)建 LLVM 15.0.7 的完整流程假設(shè)你已經(jīng)裝好了git、cmake、ninja和一個(gè)支持 C17 的編譯器GCC 7.1 或 Clang 5下面是完整的操作流程# 1. 克隆倉(cāng)庫(kù)-b 指定版本分支 git clone -b llvmorg-15.0.7 https://github.com/llvm/llvm-project.git cd llvm-project # 2. 創(chuàng)建構(gòu)建目錄保持源碼目錄干凈 mkdir build cd build # 3. CMake 配置 cmake -G Ninja ../llvm \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDX86 \ -DLLVM_USE_LINKERlld \ -DLLVM_PARALLEL_LINK_JOBS2 # 4. 開(kāi)始構(gòu)建-j 后面跟并行度 ninja -j16 # 5. 驗(yàn)證構(gòu)建結(jié)果 ./bin/llvm-config --version ./bin/clang --version第一步拉代碼時(shí)加-b參數(shù)可以避免檢出后手動(dòng)切換分支。第三步的cmake是配置階段它會(huì)檢查依賴、生成構(gòu)建文件這一步如果報(bào)錯(cuò)多半是缺包或者編譯器版本不夠。第四步ninja是真正的編譯階段參數(shù)-j16表示并行 16 個(gè)任務(wù)可以根據(jù)你的 CPU 核數(shù)調(diào)整。4. 實(shí)操用 LLVM 寫(xiě)一個(gè)優(yōu)化 Pass 并跑通4.1 先理解 Pass 是什么優(yōu)化的最小執(zhí)行單元LLVM 的優(yōu)化器由成百上千個(gè) Pass 組成每個(gè) Pass 完成一類特定的代碼變換。有些 Pass 做常量折疊——把1 2直接換成3有些做死代碼消除——?jiǎng)h掉永遠(yuǎn)不會(huì)執(zhí)行的代碼有些做循環(huán)展開(kāi)——減少循環(huán)控制開(kāi)銷(xiāo)。Pass 的機(jī)制設(shè)計(jì)得極其靈活你既可以用現(xiàn)成的 Pass 鏈跑整個(gè)優(yōu)化流程也可以只跑一個(gè)自己寫(xiě)的 Pass 來(lái)做定制化分析或變換。寫(xiě)在 Pass 里的代碼基本上就是和 IR 打交道。你需要遍歷函數(shù)、基本塊、指令讀取操作數(shù)分析數(shù)據(jù)流然后決定要不要修改。第一次寫(xiě) Pass 的時(shí)候我花了不少時(shí)間在“怎么遍歷一條指令的操作數(shù)”這種細(xì)節(jié)上后來(lái)發(fā)現(xiàn)這些 API 設(shè)計(jì)得很順手關(guān)鍵是要理解 IR 的層次結(jié)構(gòu)Module 包含函數(shù)函數(shù)包含基本塊基本塊包含指令。4.2 自己動(dòng)手寫(xiě)一個(gè)打印函數(shù)名的 FunctionPass這里我演示一個(gè)最簡(jiǎn)單的 FunctionPass功能是遍歷模塊里所有函數(shù)打印每個(gè)函數(shù)的名稱和它包含的基本塊數(shù)量。這個(gè) Pass 沒(méi)有修改 IR純做分析適合新手入門(mén)。#include llvm/IR/Function.h #include llvm/IR/Module.h #include llvm/Pass.h #include llvm/Support/raw_ostream.h using namespace llvm; namespace { struct FuncInfoPass : public FunctionPass { static char ID; FuncInfoPass() : FunctionPass(ID) {} bool runOnFunction(Function F) override { outs() Function: F.getName() , BasicBlocks: F.size() \n; return false; // 沒(méi)有修改 IR返回 false } }; } char FuncInfoPass::ID 0; static RegisterPassFuncInfoPass X(func-info, Print Function Info Pass);這段代碼的核心在runOnFunction方法F.getName()獲取函數(shù)名F.size()返回基本塊數(shù)量。outs()是 LLVM 自己封裝的輸出流相當(dāng)于std::cout。RegisterPass這個(gè)靜態(tài)對(duì)象把 Pass 注冊(cè)到opt工具里func-info是 Pass 在命令行中的名字。4.3 編譯 Pass 并用 opt 工具運(yùn)行寫(xiě)完之后需要把源碼編譯成動(dòng)態(tài)鏈接庫(kù)然后讓opt工具加載它。用 CMake 寫(xiě)一個(gè)CMakeLists.txtcmake_minimum_required(VERSION 3.13) project(FuncInfoPass) find_package(LLVM REQUIRED CONFIG) message(STATUS Found LLVM ${LLVM_PACKAGE_VERSION}) message(STATUS Using LLVMConfig.cmake in: ${LLVM_DIR}) include_directories(${LLVM_INCLUDE_DIRS}) separate_arguments(LLVM_DEFINITIONS_LIST NATIVE_COMMAND ${LLVM_DEFINITIONS}) add_compile_options(${LLVM_DEFINITIONS_LIST}) add_library(FuncInfoPass MODULE FuncInfoPass.cpp)然后執(zhí)行構(gòu)建mkdir build cd build cmake -DLLVM_DIR/path/to/llvm-project/build/lib/cmake/llvm .. make編譯完成后會(huì)生成libFuncInfoPass.so。準(zhǔn)備一個(gè)測(cè)試用的 C 文件int add(int a, int b) { return a b; } int main() { return add(1, 2); }先用clang把它編譯成 LLVM IR 文件clang -S -emit-llvm test.c -o test.ll然后加載我們的 Pass 運(yùn)行opt -load ./libFuncInfoPass.so -func-info test.ll正常的話會(huì)輸出類似下面的結(jié)果Function: add, BasicBlocks: 1 Function: main, BasicBlocks: 1就這么簡(jiǎn)單你已經(jīng)用自己的代碼“看到”了 LLVM IR 的世界。后面你想做更復(fù)雜的分析比如統(tǒng)計(jì)函數(shù)調(diào)用次數(shù)、檢查某個(gè)指令模式、做自動(dòng)改寫(xiě)思路都是在這一步上擴(kuò)展。5. llvmpipeLLVM 藏在圖形棧里的“隱身外掛”5.1 llvmpipe 到底在做什么讓 CPU 也能“畫(huà)圖”現(xiàn)在回到開(kāi)頭那個(gè)llvmpipe (LLVM 15.0.7, 256 bits)。llvmpipe 是 Mesa 項(xiàng)目中的一個(gè)軟件渲染器。所謂軟件渲染就是不用 GPU 的圖形管線完全靠 CPU 來(lái)執(zhí)行頂點(diǎn)變換、光柵化、片段著色等操作。什么時(shí)候需要這種東西沒(méi)有 GPU 的服務(wù)器、GPU 驅(qū)動(dòng)出問(wèn)題時(shí)的應(yīng)急方案、虛擬機(jī)和容器里的無(wú)頭渲染環(huán)境。llvmpipe 的聰明之處在于它沒(méi)有用傳統(tǒng)的手寫(xiě) C 循環(huán)來(lái)模擬圖形管線而是把 GLSL 著色器做成的中間表示交給 LLVM 的 JIT 編譯器實(shí)時(shí)編譯成對(duì)應(yīng) CPU 的機(jī)器碼。你寫(xiě)一個(gè)像素著色器它會(huì)為每個(gè)像素生成高效的向量化指令。這就是為什么依賴 CPU 渲染還能保持不錯(cuò)性能的原因——LLVM 的優(yōu)化器把著色器的執(zhí)行效率拉高了一大截。我曾在一臺(tái)沒(méi)有 GPU 的開(kāi)發(fā)機(jī)上用 Mesa 的GLX后端跑過(guò)一些 OpenGL 測(cè)試程序llvmpipe 的幀率雖然沒(méi)法跟獨(dú)顯比但應(yīng)付簡(jiǎn)單的離屏渲染和調(diào)試需求完全沒(méi)問(wèn)題。而且因?yàn)槟闶窃?CPU 上跑圖形管線還能用 GDB 斷點(diǎn)調(diào)試著色器代碼這在 GPU 上是不可想象的。5.2 256 bits 在說(shuō)什么從 SSE 到 AVX2 的向量化進(jìn)化日志里的256 bits指的是 llvmpipe 當(dāng)前的代碼生成目標(biāo)寬度也就是說(shuō)它正在為主機(jī) CPU 的 AVX2 指令集生成 256 位向量指令。要理解這個(gè)數(shù)字的意義得先知道 CPU 的 SIMD 指令是怎么回事。SIMD 是“單指令多數(shù)據(jù)”一條指令同時(shí)處理多個(gè)數(shù)據(jù)。老一點(diǎn)處理器上的 SSE 指令是 128 位寬一個(gè)寄存器可以同時(shí)裝下 4 個(gè) 32 位浮點(diǎn)數(shù)。AVX 把寬度翻倍到 256 位一個(gè)寄存器能裝 8 個(gè)浮點(diǎn)數(shù)。AVX-512 更進(jìn)一步到 512 位但那是重度計(jì)算場(chǎng)景才用得上的。對(duì)光柵化這種天然適合并行的任務(wù)向量化程度越高每秒鐘能處理的片段數(shù)就越多。llvmpipe 在運(yùn)行時(shí)會(huì)探測(cè) CPU 支持的指令集然后讓 LLVM 的向量器生成相應(yīng)寬度的代碼。日志里顯示 256 bits說(shuō)明它啟用了 AVX2。這一點(diǎn)對(duì)性能的影響非常直接向量寬度翻倍理論上同一條指令處理的像素?cái)?shù)也翻倍。如果你想知道當(dāng)前機(jī)器上 llvmpipe 到底能用多大的向量寬度這個(gè)日志就是最直接的答案。5.3 llvmpipe 如何借助 LLVM 的 JIT 實(shí)現(xiàn)高吞吐除了向量化llvmpipe 另一個(gè)關(guān)鍵性能手段是 JIT 編譯。傳統(tǒng)的軟件渲染器是“解釋執(zhí)行”每個(gè)片段執(zhí)行一遍獨(dú)立的邏輯開(kāi)銷(xiāo)巨大。llvmpipe 把著色器程序用 LLVM JIT 編譯成一塊完整的高效機(jī)器碼然后通過(guò)狀態(tài)管理在多個(gè)渲染目標(biāo)之間復(fù)用這塊編譯產(chǎn)物。JIT 這個(gè)技術(shù)其實(shí)和 Java 虛擬機(jī)的 JIT 是同一個(gè)思路運(yùn)行時(shí)編譯比解釋執(zhí)行快比 AOT 靜態(tài)編譯靈活。llvmpipe 的渲染循環(huán)里頂點(diǎn)著色器和片段著色器都會(huì)被單獨(dú)編譯成機(jī)器碼然后交給內(nèi)部的“繪制”邏輯去調(diào)度。它還支持多線程渲染把屏幕切分成多個(gè) tile每個(gè)線程負(fù)責(zé)一塊進(jìn)一步壓榨多核 CPU 的算力。從工程角度講llvmpipe 就是 LLVM 生態(tài)“什么都能接”的一個(gè)絕佳案例。如果沒(méi)有 LLVM 提供的 JIT 能力和優(yōu)化器Mesa 團(tuán)隊(duì)就得針對(duì)每種 CPU 架構(gòu)手寫(xiě)高性能的著色器后端那工作量是不可想象的。6. 避坑總結(jié)構(gòu)建和使用 LLVM 的常見(jiàn)問(wèn)題排查6.1 構(gòu)建階段最常踩的 5 個(gè)坑我見(jiàn)過(guò)不少人在構(gòu)建 LLVM 時(shí)翻車(chē)這里把高頻問(wèn)題整理成一張速查表問(wèn)題現(xiàn)象原因與解法編譯報(bào)錯(cuò)找不到頭文件llvm/IR/Function.h: No such file沒(méi)設(shè)置CMAKE_PREFIX_PATH或LLVM_DIR確認(rèn) llvm-config 路徑正確鏈接階段內(nèi)存不足c: fatal error: Killed signal terminated program并行鏈接任務(wù)太多降低LLVM_PARALLEL_LINK_JOBS或增加 swapGCC 版本過(guò)老報(bào)GCC 5.1之類的不支持錯(cuò)誤升級(jí)編譯器LLVM 15 需要支持 C17 的編譯器Python 腳本錯(cuò)誤FileNotFoundError: /usr/bin/python裝 python3并且確認(rèn) CMake 找到的 Python 版本符合要求ninja 串行執(zhí)行速度極慢只剩一個(gè)核在跑忘了加-j參數(shù)或 CMake 配置階段沒(méi)有生成并行規(guī)則其中內(nèi)存被殺這個(gè)問(wèn)題我印象深刻。有一臺(tái) 8 GB 內(nèi)存的舊服務(wù)器構(gòu)建時(shí)鏈接 clang 這個(gè)巨無(wú)霸經(jīng)常鏈接到一半就被內(nèi)核 OOM kill。后來(lái)我把LLVM_PARALLEL_LINK_JOBS設(shè)為 1讓鏈接串行跑編譯階段保持并行問(wèn)題迎刃而解。6.2 版本不匹配導(dǎo)致的“幽靈報(bào)錯(cuò)”LLVM 的 API 變化很快尤其是新版本之間一些接口會(huì)被重命名或者調(diào)整參數(shù)。我的建議是如果文檔寫(xiě)的是 15.0.7你的環(huán)境恰好是 17 或 18那么舊代碼大概率編譯不過(guò)。這時(shí)候不要強(qiáng)行去改代碼適配先把版本切換一致。判斷版本是否匹配最直接的方法是看llvm-config --version的輸出。構(gòu)建自己的 Pass 時(shí)一定要確保find_package(LLVM)找到的版本和opt的版本一致。我見(jiàn)過(guò)有的環(huán)境變量里同時(shí)裝著系統(tǒng)自帶的老版本 LLVM 和自行構(gòu)建的新版本結(jié)果cmake找到了老的opt拿到的是新的程序加載 Pass 直接報(bào)段錯(cuò)誤。排查方式就是用which opt和opt --version確認(rèn)實(shí)際路徑和版本。6.3 調(diào)試 Pass 時(shí)的高效工作流調(diào)試 LLVM Pass 有一套比較高效的工具組合。第一件法寶是-print-after-all它能讓你看到每個(gè) Pass 之后 IR 的變化定位到底是哪個(gè)優(yōu)化步驟改變了你的 IR。第二件法寶是-debug-onlyyour-pass-name它只打印指定 Pass 內(nèi)部的調(diào)試信息。我習(xí)慣在 Pass 里用LLVM_DEBUG(dbgs() something\n)打日志而不是用outs()。區(qū)別在于普通輸出會(huì)混在工具的正式輸出里可能導(dǎo)致寫(xiě)文件時(shí)污染數(shù)據(jù)LLVM_DEBUG的輸出只走 stderr而且可以用調(diào)試開(kāi)關(guān)控制開(kāi)關(guān)非常干凈。另外如果要分析的是某個(gè)clang源碼文件可以先只針對(duì)這個(gè)文件生成 IR再單獨(dú)跑 opt速度會(huì)快很多。沒(méi)必要每次改動(dòng) Pass 都把整個(gè)鏈接編譯重來(lái)一遍編譯動(dòng)態(tài)庫(kù)、跑 IR 文件、看結(jié)果這個(gè)循環(huán)足夠快了。7. 寫(xiě)在最后LLVM 學(xué)習(xí)路徑的一些個(gè)人體會(huì)老實(shí)說(shuō)LLVM 項(xiàng)目的代碼量是驚人的剛接觸時(shí)那種“從入門(mén)到放棄”的挫敗感我也嘗過(guò)。但如果你能熬過(guò)最初的迷茫期它帶給你的收獲是巨大的。我自己的路徑是先寫(xiě)小的 Pass用 opt 跑測(cè)試文件慢慢理解 IR 的語(yǔ)法和 Pass 的工作方式再回頭去讀 LLVM 的官方教程和源碼。這個(gè)順序比一上來(lái)就啃整個(gè)項(xiàng)目的源碼要友好得多。另外一點(diǎn)體會(huì)是llvmpipe 這類“LLVM 的跨界應(yīng)用”最值得琢磨因?yàn)樗故玖司幾g技術(shù)在非編譯器領(lǐng)域的生命力。你不需要只會(huì)寫(xiě)編譯器才能受益于 LLVM做渲染的可以用它做軟件管線做數(shù)據(jù)庫(kù)的可以用它做查詢編譯做 AI 框架的可以用它優(yōu)化算子。這種可復(fù)用性才是 LLVM 這十幾年生命力不倒的真正秘訣。 深入淺出LLVM：編譯器架構(gòu)、優(yōu)化Pass與llvmpipe軟件渲染實(shí)戰(zhàn)
1. LLVM到底是個(gè)什么項(xiàng)目從一次排查渲染問(wèn)題說(shuō)起前陣子有同事給我發(fā)來(lái)一條日志上面寫(xiě)著llvmpipe (LLVM 15.0.7, 256 bits)問(wèn)我這行字是什么意思是不是系統(tǒng)出了故障。我一看就樂(lè)了——這哪是故障這是你的軟件渲染器在老實(shí)交代自己的“底牌”。llvmpipe是 Mesa 圖形棧里的 CPU 軟件渲染實(shí)現(xiàn)它背后站著的是 LLVM 這個(gè)編譯器基礎(chǔ)設(shè)施。如果只看名字很多人以為 llvmpipe 是某種管道工具其實(shí)它的意思是“用 LLVM 實(shí)現(xiàn)的軟件像素管線”。說(shuō)到 LLVM很多人第一反應(yīng)是“哦Clang 編譯器”。這個(gè)理解沒(méi)錯(cuò)但太窄了。LLVM 是一個(gè)龐大的編譯器基礎(chǔ)設(shè)施項(xiàng)目Clang 只是它上面的一個(gè)前端。從手機(jī) App 到游戲引擎從 GPU 驅(qū)動(dòng)到編程語(yǔ)言工具鏈背后都有 LLVM 的身影。我自己最早接觸 LLVM 是為了搞清楚編譯器優(yōu)化到底在優(yōu)化什么結(jié)果一頭扎進(jìn)去就再?zèng)]出來(lái)——這個(gè)項(xiàng)目的設(shè)計(jì)思路、工程組織、社區(qū)文化在開(kāi)源世界里幾乎找不到第二個(gè)同級(jí)別的存在。這篇文章我想從一個(gè)軟件渲染日志中的256 bits說(shuō)起把 LLVM 項(xiàng)目的整體結(jié)構(gòu)、核心設(shè)計(jì)、實(shí)際操作和避坑經(jīng)驗(yàn)一次講清楚。不管你是做編譯器開(kāi)發(fā)的、寫(xiě) GPU 驅(qū)動(dòng)的、還是單純想搞懂“編譯器是怎么工作的”這篇文章應(yīng)該都能給你一些參考。2. 三段式架構(gòu)為什么 LLVM 能“一招鮮吃遍天”2.1 從“翻譯官”到“萬(wàn)能中間層”傳統(tǒng)編譯器的結(jié)構(gòu)是“前端 后端”前端解析源代碼生成中間表示后端把中間表示翻譯成目標(biāo)機(jī)器碼。問(wèn)題在于前端和后端是一一綁定的來(lái)一個(gè)新語(yǔ)言就要寫(xiě)一套完整工具鏈來(lái)一個(gè)新 CPU 架構(gòu)又要重寫(xiě)一遍后端。這種模式的維護(hù)成本極高而且優(yōu)化邏輯分散在前后端里很難統(tǒng)一復(fù)用。LLVM 的設(shè)計(jì)思路從根本上改變了這個(gè)局面。它把編譯器拆成了三段前端Frontend、中端優(yōu)化器Optimizer、后端Backend。前端把源代碼翻譯成 LLVM IR這是一個(gè)獨(dú)立于具體語(yǔ)言和具體硬件的中間表示中端優(yōu)化器針對(duì) IR 做各種通用的優(yōu)化后端再把優(yōu)化后的 IR 翻譯成目標(biāo)平臺(tái)的機(jī)器碼。我習(xí)慣用一個(gè)翻譯公司的例子來(lái)解釋前端是“中文翻譯成世界語(yǔ)”的譯員中端是“把世界語(yǔ)文本潤(rùn)色改稿”的編輯后端是“把世界語(yǔ)翻譯成英文、日文、法文”的另一批譯員。世界語(yǔ)就是 LLVM IR它本身不是最終產(chǎn)物但它讓整個(gè)流程可以靈活組合——來(lái)一門(mén)新語(yǔ)言只需要新招一個(gè)“中文翻譯成世界語(yǔ)”的譯員其他環(huán)節(jié)全部復(fù)用。這個(gè)設(shè)計(jì)的威力在哪兒一個(gè)編程語(yǔ)言社區(qū)想做自己的編譯器只要寫(xiě)一個(gè)前端生成 LLVM IR就能立刻獲得全套優(yōu)化、調(diào)試、代碼生成能力。一個(gè)芯片廠商想支持新指令集只要寫(xiě)好 LLVM 后端所有基于 LLVM 的語(yǔ)言都能跑上新硬件。這就是 LLVM 能成為“編譯器領(lǐng)域的 Linux”的根本原因。2.2 IR 的三層表示為什么調(diào)試信息能跨越整個(gè)編譯流程LLVM IR 不是一個(gè)單一的形態(tài)它有三層表示內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)、文本形式的.ll文件、二進(jìn)制形式的.bc文件。這聽(tīng)起來(lái)像純工程實(shí)現(xiàn)細(xì)節(jié)但它對(duì)實(shí)際開(kāi)發(fā)的影響非常大。文本形式.ll是可讀的方便調(diào)試和分析優(yōu)化過(guò)程。我在寫(xiě) Pass 的時(shí)候經(jīng)常把 IR 打印出來(lái)逐條檢查優(yōu)化前后的差異。二進(jìn)制形式.bc適合存儲(chǔ)和快速加載常用于鏈接時(shí)優(yōu)化的場(chǎng)景。內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)則是編譯器運(yùn)行時(shí)的真實(shí)狀態(tài)。更關(guān)鍵的是IR 從生成到變成機(jī)器碼一直保留著源代碼層面的元數(shù)據(jù)。變量名、文件路徑、行號(hào)、類型信息都掛在 IR 的指令和函數(shù)上。這意味著你在調(diào)試優(yōu)化后的代碼時(shí)還能把機(jī)器碼準(zhǔn)確地映射回源代碼——這個(gè)能力叫 DWARF 調(diào)試信息它讓 GDB、LLDB 等調(diào)試器能正常工作。沒(méi)有這個(gè)設(shè)計(jì)編譯器優(yōu)化做得再漂亮調(diào)試體驗(yàn)也會(huì)一團(tuán)糟。2.3 項(xiàng)目倉(cāng)庫(kù)里到底裝了什么一次目錄掃盲很多初學(xué)者 clone 下 llvm-project 倉(cāng)庫(kù)之后看著根目錄下那一大堆文件夾直接懵了。我來(lái)幫你掃一遍最重要的目錄llvm/核心目錄包含 LLVM 的基礎(chǔ)庫(kù)、優(yōu)化器、后端、IR 定義、工具鏈。clang/C/C/Objective-C 的前端這是 LLVM 最重要的前端實(shí)現(xiàn)。lld/高性能鏈接器鏈接速度比 GNU ld 快很多我自己實(shí)測(cè)大項(xiàng)目鏈接能快兩三倍。compiler-rt/運(yùn)行時(shí)庫(kù)提供諸如地址消毒器ASan、未定義行為消毒器UBSan等工具的支持。libcxx/和libcxxabi/C 標(biāo)準(zhǔn)庫(kù)和 ABI 庫(kù)的實(shí)現(xiàn)。flang/Fortran 語(yǔ)言前端科研和 HPC 領(lǐng)域用得比較多。mlir/MLIR 項(xiàng)目專門(mén)為機(jī)器學(xué)習(xí)編譯器設(shè)計(jì)的多層中間表示框架現(xiàn)在已經(jīng)是 AI 編譯器的核心基礎(chǔ)設(shè)施。polly/基于多面體模型的循環(huán)優(yōu)化框架偏學(xué)術(shù)研究方向。clang-tools-extra/各種 Clang 輔助工具比如 clang-tidy、clang-format。這套結(jié)構(gòu)體現(xiàn)了 LLVM 的設(shè)計(jì)哲學(xué)每個(gè)子項(xiàng)目都是獨(dú)立可用的組件組合在一起又是一個(gè)完整的工具鏈。你可以只拿 clang-format 這個(gè)工具來(lái)規(guī)范代碼風(fēng)格也可以把整個(gè) LLVM 作為依賴集成進(jìn)自己的產(chǎn)品里。3. 核心組件與構(gòu)建系統(tǒng)先把工程踩熟3.1 CMake 配置決定你接下來(lái)幾個(gè)小時(shí)命運(yùn)的參數(shù)LLVM 使用 CMake 作為構(gòu)建系統(tǒng)。這不是簡(jiǎn)單的“運(yùn)行 cmake 然后 make”的問(wèn)題幾個(gè)關(guān)鍵參數(shù)的選擇直接決定構(gòu)建耗時(shí)和最終產(chǎn)物質(zhì)量。我把自己常用的參數(shù)整理成一個(gè)表參數(shù)推薦值作用與理由LLVM_ENABLE_PROJECTSclang;lld指定額外構(gòu)建的子項(xiàng)目用分號(hào)分隔構(gòu)建順序有依賴關(guān)系LLVM_TARGETS_TO_BUILDX86只構(gòu)建需要的目標(biāo)架構(gòu)后端全量構(gòu)建會(huì)消耗大量時(shí)間和磁盤(pán)CMAKE_BUILD_TYPERelease或RelWithDebInfoRelease 性能好RelWithDebInfo 保留調(diào)試信息調(diào)試用后者LLVM_USE_LINKERlld或gold鏈接器選擇大項(xiàng)目鏈接時(shí) lld 能省大量時(shí)間LLVM_PARALLEL_LINK_JOBS2或4限制并行鏈接任務(wù)數(shù)防止鏈接階段內(nèi)存爆掉LLVM_ENABLE_ASSERTIONSON開(kāi)發(fā)時(shí)開(kāi)啟斷言能幫你早期發(fā)現(xiàn)問(wèn)題但會(huì)拖慢性能我踩過(guò)最大的坑就是第一次構(gòu)建時(shí)沒(méi)設(shè)置LLVM_TARGETS_TO_BUILD結(jié)果全量構(gòu)建了所有后端包括我根本用不到的 AArch64、PowerPC、MIPS磁盤(pán)直接被吃掉幾十 GB。第二次學(xué)乖了只保留 X86構(gòu)建時(shí)間縮短了一半以上。3.2 構(gòu)建機(jī)器的最低配置與時(shí)間預(yù)期LLVM 構(gòu)建是 CPU 密集型的活兒建議至少 8 核 16 線程以上的機(jī)器。16 GB 內(nèi)存是底線如果你開(kāi)啟了并行鏈接建議 32 GB。磁盤(pán)方面光源碼就得 1-2 GB構(gòu)建產(chǎn)物按配置不同要 20-50 GB。如果你打算用ccache做增量編譯緩存那再加 20 GB 也不嫌多。構(gòu)建時(shí)間因機(jī)器而異。一臺(tái) 16 核的現(xiàn)代機(jī)器全量構(gòu)建 LLVM Clang lld 的 Release 版本大概需要 30-60 分鐘。配置越全、調(diào)試信息越多時(shí)間越長(zhǎng)。我試過(guò)在一臺(tái) 4 核老機(jī)器上構(gòu)建整整跑了三個(gè)多小時(shí)中途還因?yàn)閮?nèi)存不夠崩了兩次。所以如果你只是學(xué)習(xí)用建議先只構(gòu)建llvm本體的工具鏈沒(méi)必要一上來(lái)就全量構(gòu)建所有子項(xiàng)目。3.3 從源碼構(gòu)建 LLVM 15.0.7 的完整流程假設(shè)你已經(jīng)裝好了git、cmake、ninja和一個(gè)支持 C17 的編譯器GCC 7.1 或 Clang 5下面是完整的操作流程# 1. 克隆倉(cāng)庫(kù)-b 指定版本分支 git clone -b llvmorg-15.0.7 https://github.com/llvm/llvm-project.git cd llvm-project # 2. 創(chuàng)建構(gòu)建目錄保持源碼目錄干凈 mkdir build cd build # 3. CMake 配置 cmake -G Ninja ../llvm \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDX86 \ -DLLVM_USE_LINKERlld \ -DLLVM_PARALLEL_LINK_JOBS2 # 4. 開(kāi)始構(gòu)建-j 后面跟并行度 ninja -j16 # 5. 驗(yàn)證構(gòu)建結(jié)果 ./bin/llvm-config --version ./bin/clang --version第一步拉代碼時(shí)加-b參數(shù)可以避免檢出后手動(dòng)切換分支。第三步的cmake是配置階段它會(huì)檢查依賴、生成構(gòu)建文件這一步如果報(bào)錯(cuò)多半是缺包或者編譯器版本不夠。第四步ninja是真正的編譯階段參數(shù)-j16表示并行 16 個(gè)任務(wù)可以根據(jù)你的 CPU 核數(shù)調(diào)整。4. 實(shí)操用 LLVM 寫(xiě)一個(gè)優(yōu)化 Pass 并跑通4.1 先理解 Pass 是什么優(yōu)化的最小執(zhí)行單元LLVM 的優(yōu)化器由成百上千個(gè) Pass 組成每個(gè) Pass 完成一類特定的代碼變換。有些 Pass 做常量折疊——把1 2直接換成3有些做死代碼消除——?jiǎng)h掉永遠(yuǎn)不會(huì)執(zhí)行的代碼有些做循環(huán)展開(kāi)——減少循環(huán)控制開(kāi)銷(xiāo)。Pass 的機(jī)制設(shè)計(jì)得極其靈活你既可以用現(xiàn)成的 Pass 鏈跑整個(gè)優(yōu)化流程也可以只跑一個(gè)自己寫(xiě)的 Pass 來(lái)做定制化分析或變換。寫(xiě)在 Pass 里的代碼基本上就是和 IR 打交道。你需要遍歷函數(shù)、基本塊、指令讀取操作數(shù)分析數(shù)據(jù)流然后決定要不要修改。第一次寫(xiě) Pass 的時(shí)候我花了不少時(shí)間在“怎么遍歷一條指令的操作數(shù)”這種細(xì)節(jié)上后來(lái)發(fā)現(xiàn)這些 API 設(shè)計(jì)得很順手關(guān)鍵是要理解 IR 的層次結(jié)構(gòu)Module 包含函數(shù)函數(shù)包含基本塊基本塊包含指令。4.2 自己動(dòng)手寫(xiě)一個(gè)打印函數(shù)名的 FunctionPass這里我演示一個(gè)最簡(jiǎn)單的 FunctionPass功能是遍歷模塊里所有函數(shù)打印每個(gè)函數(shù)的名稱和它包含的基本塊數(shù)量。這個(gè) Pass 沒(méi)有修改 IR純做分析適合新手入門(mén)。#include llvm/IR/Function.h #include llvm/IR/Module.h #include llvm/Pass.h #include llvm/Support/raw_ostream.h using namespace llvm; namespace { struct FuncInfoPass : public FunctionPass { static char ID; FuncInfoPass() : FunctionPass(ID) {} bool runOnFunction(Function F) override { outs() Function: F.getName() , BasicBlocks: F.size() \n; return false; // 沒(méi)有修改 IR返回 false } }; } char FuncInfoPass::ID 0; static RegisterPassFuncInfoPass X(func-info, Print Function Info Pass);這段代碼的核心在runOnFunction方法F.getName()獲取函數(shù)名F.size()返回基本塊數(shù)量。outs()是 LLVM 自己封裝的輸出流相當(dāng)于std::cout。RegisterPass這個(gè)靜態(tài)對(duì)象把 Pass 注冊(cè)到opt工具里func-info是 Pass 在命令行中的名字。4.3 編譯 Pass 并用 opt 工具運(yùn)行寫(xiě)完之后需要把源碼編譯成動(dòng)態(tài)鏈接庫(kù)然后讓opt工具加載它。用 CMake 寫(xiě)一個(gè)CMakeLists.txtcmake_minimum_required(VERSION 3.13) project(FuncInfoPass) find_package(LLVM REQUIRED CONFIG) message(STATUS Found LLVM ${LLVM_PACKAGE_VERSION}) message(STATUS Using LLVMConfig.cmake in: ${LLVM_DIR}) include_directories(${LLVM_INCLUDE_DIRS}) separate_arguments(LLVM_DEFINITIONS_LIST NATIVE_COMMAND ${LLVM_DEFINITIONS}) add_compile_options(${LLVM_DEFINITIONS_LIST}) add_library(FuncInfoPass MODULE FuncInfoPass.cpp)然后執(zhí)行構(gòu)建mkdir build cd build cmake -DLLVM_DIR/path/to/llvm-project/build/lib/cmake/llvm .. make編譯完成后會(huì)生成libFuncInfoPass.so。準(zhǔn)備一個(gè)測(cè)試用的 C 文件int add(int a, int b) { return a b; } int main() { return add(1, 2); }先用clang把它編譯成 LLVM IR 文件clang -S -emit-llvm test.c -o test.ll然后加載我們的 Pass 運(yùn)行opt -load ./libFuncInfoPass.so -func-info test.ll正常的話會(huì)輸出類似下面的結(jié)果Function: add, BasicBlocks: 1 Function: main, BasicBlocks: 1就這么簡(jiǎn)單你已經(jīng)用自己的代碼“看到”了 LLVM IR 的世界。后面你想做更復(fù)雜的分析比如統(tǒng)計(jì)函數(shù)調(diào)用次數(shù)、檢查某個(gè)指令模式、做自動(dòng)改寫(xiě)思路都是在這一步上擴(kuò)展。5. llvmpipeLLVM 藏在圖形棧里的“隱身外掛”5.1 llvmpipe 到底在做什么讓 CPU 也能“畫(huà)圖”現(xiàn)在回到開(kāi)頭那個(gè)llvmpipe (LLVM 15.0.7, 256 bits)。llvmpipe 是 Mesa 項(xiàng)目中的一個(gè)軟件渲染器。所謂軟件渲染就是不用 GPU 的圖形管線完全靠 CPU 來(lái)執(zhí)行頂點(diǎn)變換、光柵化、片段著色等操作。什么時(shí)候需要這種東西沒(méi)有 GPU 的服務(wù)器、GPU 驅(qū)動(dòng)出問(wèn)題時(shí)的應(yīng)急方案、虛擬機(jī)和容器里的無(wú)頭渲染環(huán)境。llvmpipe 的聰明之處在于它沒(méi)有用傳統(tǒng)的手寫(xiě) C 循環(huán)來(lái)模擬圖形管線而是把 GLSL 著色器做成的中間表示交給 LLVM 的 JIT 編譯器實(shí)時(shí)編譯成對(duì)應(yīng) CPU 的機(jī)器碼。你寫(xiě)一個(gè)像素著色器它會(huì)為每個(gè)像素生成高效的向量化指令。這就是為什么依賴 CPU 渲染還能保持不錯(cuò)性能的原因——LLVM 的優(yōu)化器把著色器的執(zhí)行效率拉高了一大截。我曾在一臺(tái)沒(méi)有 GPU 的開(kāi)發(fā)機(jī)上用 Mesa 的GLX后端跑過(guò)一些 OpenGL 測(cè)試程序llvmpipe 的幀率雖然沒(méi)法跟獨(dú)顯比但應(yīng)付簡(jiǎn)單的離屏渲染和調(diào)試需求完全沒(méi)問(wèn)題。而且因?yàn)槟闶窃?CPU 上跑圖形管線還能用 GDB 斷點(diǎn)調(diào)試著色器代碼這在 GPU 上是不可想象的。5.2 256 bits 在說(shuō)什么從 SSE 到 AVX2 的向量化進(jìn)化日志里的256 bits指的是 llvmpipe 當(dāng)前的代碼生成目標(biāo)寬度也就是說(shuō)它正在為主機(jī) CPU 的 AVX2 指令集生成 256 位向量指令。要理解這個(gè)數(shù)字的意義得先知道 CPU 的 SIMD 指令是怎么回事。SIMD 是“單指令多數(shù)據(jù)”一條指令同時(shí)處理多個(gè)數(shù)據(jù)。老一點(diǎn)處理器上的 SSE 指令是 128 位寬一個(gè)寄存器可以同時(shí)裝下 4 個(gè) 32 位浮點(diǎn)數(shù)。AVX 把寬度翻倍到 256 位一個(gè)寄存器能裝 8 個(gè)浮點(diǎn)數(shù)。AVX-512 更進(jìn)一步到 512 位但那是重度計(jì)算場(chǎng)景才用得上的。對(duì)光柵化這種天然適合并行的任務(wù)向量化程度越高每秒鐘能處理的片段數(shù)就越多。llvmpipe 在運(yùn)行時(shí)會(huì)探測(cè) CPU 支持的指令集然后讓 LLVM 的向量器生成相應(yīng)寬度的代碼。日志里顯示 256 bits說(shuō)明它啟用了 AVX2。這一點(diǎn)對(duì)性能的影響非常直接向量寬度翻倍理論上同一條指令處理的像素?cái)?shù)也翻倍。如果你想知道當(dāng)前機(jī)器上 llvmpipe 到底能用多大的向量寬度這個(gè)日志就是最直接的答案。5.3 llvmpipe 如何借助 LLVM 的 JIT 實(shí)現(xiàn)高吞吐除了向量化llvmpipe 另一個(gè)關(guān)鍵性能手段是 JIT 編譯。傳統(tǒng)的軟件渲染器是“解釋執(zhí)行”每個(gè)片段執(zhí)行一遍獨(dú)立的邏輯開(kāi)銷(xiāo)巨大。llvmpipe 把著色器程序用 LLVM JIT 編譯成一塊完整的高效機(jī)器碼然后通過(guò)狀態(tài)管理在多個(gè)渲染目標(biāo)之間復(fù)用這塊編譯產(chǎn)物。JIT 這個(gè)技術(shù)其實(shí)和 Java 虛擬機(jī)的 JIT 是同一個(gè)思路運(yùn)行時(shí)編譯比解釋執(zhí)行快比 AOT 靜態(tài)編譯靈活。llvmpipe 的渲染循環(huán)里頂點(diǎn)著色器和片段著色器都會(huì)被單獨(dú)編譯成機(jī)器碼然后交給內(nèi)部的“繪制”邏輯去調(diào)度。它還支持多線程渲染把屏幕切分成多個(gè) tile每個(gè)線程負(fù)責(zé)一塊進(jìn)一步壓榨多核 CPU 的算力。從工程角度講llvmpipe 就是 LLVM 生態(tài)“什么都能接”的一個(gè)絕佳案例。如果沒(méi)有 LLVM 提供的 JIT 能力和優(yōu)化器Mesa 團(tuán)隊(duì)就得針對(duì)每種 CPU 架構(gòu)手寫(xiě)高性能的著色器后端那工作量是不可想象的。6. 避坑總結(jié)構(gòu)建和使用 LLVM 的常見(jiàn)問(wèn)題排查6.1 構(gòu)建階段最常踩的 5 個(gè)坑我見(jiàn)過(guò)不少人在構(gòu)建 LLVM 時(shí)翻車(chē)這里把高頻問(wèn)題整理成一張速查表問(wèn)題現(xiàn)象原因與解法編譯報(bào)錯(cuò)找不到頭文件llvm/IR/Function.h: No such file沒(méi)設(shè)置CMAKE_PREFIX_PATH或LLVM_DIR確認(rèn) llvm-config 路徑正確鏈接階段內(nèi)存不足c: fatal error: Killed signal terminated program并行鏈接任務(wù)太多降低LLVM_PARALLEL_LINK_JOBS或增加 swapGCC 版本過(guò)老報(bào)GCC 5.1之類的不支持錯(cuò)誤升級(jí)編譯器LLVM 15 需要支持 C17 的編譯器Python 腳本錯(cuò)誤FileNotFoundError: /usr/bin/python裝 python3并且確認(rèn) CMake 找到的 Python 版本符合要求ninja 串行執(zhí)行速度極慢只剩一個(gè)核在跑忘了加-j參數(shù)或 CMake 配置階段沒(méi)有生成并行規(guī)則其中內(nèi)存被殺這個(gè)問(wèn)題我印象深刻。有一臺(tái) 8 GB 內(nèi)存的舊服務(wù)器構(gòu)建時(shí)鏈接 clang 這個(gè)巨無(wú)霸經(jīng)常鏈接到一半就被內(nèi)核 OOM kill。后來(lái)我把LLVM_PARALLEL_LINK_JOBS設(shè)為 1讓鏈接串行跑編譯階段保持并行問(wèn)題迎刃而解。6.2 版本不匹配導(dǎo)致的“幽靈報(bào)錯(cuò)”LLVM 的 API 變化很快尤其是新版本之間一些接口會(huì)被重命名或者調(diào)整參數(shù)。我的建議是如果文檔寫(xiě)的是 15.0.7你的環(huán)境恰好是 17 或 18那么舊代碼大概率編譯不過(guò)。這時(shí)候不要強(qiáng)行去改代碼適配先把版本切換一致。判斷版本是否匹配最直接的方法是看llvm-config --version的輸出。構(gòu)建自己的 Pass 時(shí)一定要確保find_package(LLVM)找到的版本和opt的版本一致。我見(jiàn)過(guò)有的環(huán)境變量里同時(shí)裝著系統(tǒng)自帶的老版本 LLVM 和自行構(gòu)建的新版本結(jié)果cmake找到了老的opt拿到的是新的程序加載 Pass 直接報(bào)段錯(cuò)誤。排查方式就是用which opt和opt --version確認(rèn)實(shí)際路徑和版本。6.3 調(diào)試 Pass 時(shí)的高效工作流調(diào)試 LLVM Pass 有一套比較高效的工具組合。第一件法寶是-print-after-all它能讓你看到每個(gè) Pass 之后 IR 的變化定位到底是哪個(gè)優(yōu)化步驟改變了你的 IR。第二件法寶是-debug-onlyyour-pass-name它只打印指定 Pass 內(nèi)部的調(diào)試信息。我習(xí)慣在 Pass 里用LLVM_DEBUG(dbgs() something\n)打日志而不是用outs()。區(qū)別在于普通輸出會(huì)混在工具的正式輸出里可能導(dǎo)致寫(xiě)文件時(shí)污染數(shù)據(jù)LLVM_DEBUG的輸出只走 stderr而且可以用調(diào)試開(kāi)關(guān)控制開(kāi)關(guān)非常干凈。另外如果要分析的是某個(gè)clang源碼文件可以先只針對(duì)這個(gè)文件生成 IR再單獨(dú)跑 opt速度會(huì)快很多。沒(méi)必要每次改動(dòng) Pass 都把整個(gè)鏈接編譯重來(lái)一遍編譯動(dòng)態(tài)庫(kù)、跑 IR 文件、看結(jié)果這個(gè)循環(huán)足夠快了。7. 寫(xiě)在最后LLVM 學(xué)習(xí)路徑的一些個(gè)人體會(huì)老實(shí)說(shuō)LLVM 項(xiàng)目的代碼量是驚人的剛接觸時(shí)那種“從入門(mén)到放棄”的挫敗感我也嘗過(guò)。但如果你能熬過(guò)最初的迷茫期它帶給你的收獲是巨大的。我自己的路徑是先寫(xiě)小的 Pass用 opt 跑測(cè)試文件慢慢理解 IR 的語(yǔ)法和 Pass 的工作方式再回頭去讀 LLVM 的官方教程和源碼。這個(gè)順序比一上來(lái)就啃整個(gè)項(xiàng)目的源碼要友好得多。另外一點(diǎn)體會(huì)是llvmpipe 這類“LLVM 的跨界應(yīng)用”最值得琢磨因?yàn)樗故玖司幾g技術(shù)在非編譯器領(lǐng)域的生命力。你不需要只會(huì)寫(xiě)編譯器才能受益于 LLVM做渲染的可以用它做軟件管線做數(shù)據(jù)庫(kù)的可以用它做查詢編譯做 AI 框架的可以用它優(yōu)化算子。這種可復(fù)用性才是 LLVM 這十幾年生命力不倒的真正秘訣。