歡迎有潛力的 2025 年 Google 程式碼夏令營學生！本文檔是您尋找 LLVM、Clang 和其他相關子專案中有趣且重要專案的起點。此專案列表不僅為 Google 程式碼夏令營開發，也為真正需要開發人員投入且對 LLVM 社群非常有益的開放專案而開發。

我們鼓勵您瀏覽此列表，看看哪些專案讓您感到興奮，並與您的技能組合非常吻合。我們也歡迎未在此列表中的提案。有關 GSoC 的更多資訊和討論，請參閱 discourse 。如果您對特定專案有疑問，請在 discourse 中找到相關條目，查看先前的討論並提問。如果沒有此類條目，或者您想提出想法，請建立一個新條目。來自社群的回饋是您的提案被考慮並希望被接受的要求。

LLVM 專案已參與 Google 程式碼夏令營多年，並取得了一些非常成功的專案。我們希望今年也不例外，並期待收到您的提案。有關如何提交提案的資訊，請造訪 Google 程式碼夏令營主要網站。

描述

使用來自除錯資訊的變數位置資訊，以來源變數的位置和生命週期註解 LLDB 的反組譯器 (和 `register read`) 輸出。豐富的反組譯器輸出應公開為結構化資料，並透過 LLDB 的腳本 API 提供，以便可以在此基礎上建置更多工具。在終端機中，LLDB 應將註解呈現為文字。

預期成果

frame #0: 0x0000000100000f80 a.out`main(argc=1, argv=0x00007ff7bfeff1d8) at demo.c:4:10 [opt]
  1   void puts(const char*);
  2   int main(int argc, char **argv) {
  3    for (int i = 0; i < argc; ++i)
→ 4      puts(argv[i]);
  5    return 0;
  6   }
(lldb) disassemble
a.out`main:
...
  0x100000f71 <+17>: movl  %edi, %r14d
  0x100000f74 <+20>: xorl  %r15d, %r15d
  0x100000f77 <+23>: nopw  (%rax,%rax)
→  0x100000f80 <+32>: movq  (%rbx,%r15,8), %rdi
  0x100000f84 <+36>: callq 0x100000f9e ; symbol stub for: puts
  0x100000f89 <+41>: incq  %r15
  0x100000f8c <+44>: cmpq  %r15, %r14
  0x100000f8f <+47>: jne 0x100000f80 ; <+32> at demo.c:4:10
  0x100000f91 <+49>: addq  $0x8, %rsp
  0x100000f95 <+53>: popq  %rbx
...

使用 LLDB 也可存取的除錯資訊 (觀察來源變數 i 如何從 [0x100000f77+slide) 開始在 r15 中)

$ dwarfdump demo.dSYM --name  i
demo.dSYM/Contents/Resources/DWARF/demo: file format Mach-O 64-bit x86-64
0x00000076: DW_TAG_variable
 DW_AT_location (0x00000098:
 [0x0000000100000f60, 0x0000000100000f77): DW_OP_consts +0, DW_OP_stack_value
 [0x0000000100000f77, 0x0000000100000f91): DW_OP_reg15 R15)
 DW_AT_name ("i")
 DW_AT_decl_file ("/tmp/t.c")
 DW_AT_decl_line (3)
 DW_AT_type (0x000000b2 "int")

(lldb) disassemble
a.out`main:
...                                                               ; i=0
  0x100000f74 <+20>: xorl  %r15d, %r15d                           ; i=r15
  0x100000f77 <+23>: nopw  (%rax,%rax)                            ; |
→  0x100000f80 <+32>: movq  (%rbx,%r15,8), %rdi                   ; |
  0x100000f84 <+36>: callq 0x100000f9e ; symbol stub for: puts    ; |
  0x100000f89 <+41>: incq  %r15                                   ; |
  0x100000f8c <+44>: cmpq  %r15, %r14                             ; |
  0x100000f8f <+47>: jne 0x100000f80 ; <+32> at t.c:4:10          ; |
  0x100000f91 <+49>: addq  $0x8, %rsp                             ; i=undef
  0x100000f95 <+53>: popq  %rbx

目標是為一組明確的案例產生像這樣的輸出，例如，常數或完全在暫存器中的變數。

已確認的導師及其聯絡方式

• Adrian Prantl aprantl@apple.com (主要聯絡人)
• Jonas Devlieghere jdevlieghere@apple.com

所需/期望的技能

必要條件

• 良好的 C++ 理解能力
• 熟悉在終端機上使用除錯器
• 需要熟悉上面範例中提及的所有概念
• 需要充分理解至少一種機器碼的組合語言 (x86_64 或 AArch64)。

期望條件

• 編譯器知識，包括資料流和控制流分析，是加分項。
• 能夠瀏覽除錯資訊 (DWARF) 是加分項。

專案規模

中等 (~175 小時)

專案難度

困難

Discourse: 網址

描述

Bfloat16 是一種最近開發的浮點格式，專為機器學習和 AI 量身定制，並且在最新的 C++23 標準中，它已正式標準化為 std::bfloat16_t。它的支援可以在許多現代硬體中找到，從包括 Intel、AMD、Apple 和 Amazon 在內的所有主要供應商的 CPU，到 GPU (nVidia 和 AMD GPU) 和 Google TPU。在軟體方面，所有主要的加速器程式庫都支援它，例如 CUDA、ROCm、oneAPI、PyTorch 和 Tensorflow。此專案的目標是在 LLVM libc 程式庫中實作 bfloat16 數學函式。

預期結果

• 正確設定產生的標頭，以便類型和函式可以與各種編譯器 (+版本) 和架構一起使用。
• 實作通用的基本數學運算，以支援在支援的架構上運作的 bfloat16 資料類型：x86_64、arm (32 + 64)、risc-v (32 + 64) 和 GPU。
• 盡可能使用編譯器內建函數或特殊硬體指令來實作特化，以提高其效能。
• 如果時間允許，我們可以開始研究 bfloat16 的更高階數學函式。

技能

基本 C 和 C++ 技能 + 對了解/學習更多關於浮點格式精妙之處的興趣。

專案規模： 大型

難度： 簡單/中等

已確認的導師： Tue Ly、Nicolas Celik、

Discourse: 網址

描述

現代 GPU 能夠與主機進行統一尋址。我們目前使用它透過 RPC 介面提供 I/O 支援。但是，這需要在 CPU 上使用專用的使用者執行緒來處理伺服器程式碼。我們希望探索替代方案，以使用 Linux io_uring 介面從 GPU 提供 I/O。

此介面是一個環形緩衝區，旨在加速系統呼叫。但是，它提供了一種 輪詢模式，允許核心刷新環形緩衝區，而無需使用者啟動系統呼叫。我們應該能夠使用 AMD 和 NVIDIA API 呼叫向 GPU 註冊 mmap() 記憶體。此介面應允許我們實作基本的讀/寫介面，該介面可以被認為與 CPU 上的系統呼叫相同。然後，它可以用於實作完整檔案介面。

預期結果

• 在 GPU 上執行的 pwrite 和 pread 的實作。
• 透過將 snprintf 轉發到 pwrite 來支援 printf。
• 如果時間允許，探索 GPU 檔案 API。

技能

基本 C 和 C++ 技能 + 存取 GPU、Linux 核心知識、GPU 知識。

專案規模： 小型

難度： 困難

已確認的導師： Joseph Huber、Tian Shilei

Discourse: 網址

描述

LLVM C 程式庫提供了數學函式的實作。我們希望根據現有的實作 (例如 CUDA 的 libdevice、ROCm 的 device libs 和 OpenCL 的 libclc) 來分析這些函式。去年，我們致力於一些介面來支援這些測試，現在需要改進這些介面，並為有趣的函式填寫內容。

此外，我們希望驗證這些函式在 GPU 上執行時的準確性，方法是透過暴力測試。目標是驗證實作是否正確，並且至少符合 OpenCL 標準中的誤差範圍。這將需要一組以 offload/ 專案撰寫的單元測試，理想情況下是使用 @callumfare 正在開發的新 API。

預期結果

• 最終效能結果類似於 舊結果，但具有更最佳化的函式和更高的準確性。
• 一個可以進行暴力測試以確認實作符合規範的測試套件。

技能

基本 C 和 C++ 技能 + 存取 GPU、一些數學知識

專案規模： 小型

難度： 簡單/中等

已確認的導師： Joseph Huber、Tue Ly

Discourse: 網址

描述： ClangIR (CIR) 專案旨在為 Clang 建立新的中間表示法 (IR)。它建立在 MLIR 之上，為 Clang 中基於 C/C++ 的語言提供方言，以及從 Clang AST 發射它所需的基礎架構，以及到 LLVM-IR 方言的降低路徑。ClangIR 上游化目前正在進行中。

為了向社群提供更頻繁的更新，如果我們可以透過衡量在啟用 ClangIR 的管道中現有 Clang 的 CodeGen 測試的覆蓋率來報告 ClangIR 的進度，那就太好了。透過收集有關崩潰、通過或失敗測試的資訊，我們可以提出一個更容易報告和理解的指標，為尋找任務的新手提供切入點，並透過對現有問題進行分類來幫助專案。現有的 Clang CodeGen 測試位於 clang/test/CodeGen* 中，並且在 ClangIR 支援方面可能處於不同的狀態

• FileCheck 失敗。LLVM IR 建置成功，但 FileCheck 無法比對輸出
  • LLVM IR 不同，因為 ClangIR 管道正在發射不同的 IR (例如，使用了不同的指令、遺失了屬性)。需要建立問題，並且需要修正 ClangIR。
  • LLVM IR 不同，因為 CHECK 行需要更靈活 (LLVM-IR 方言輸出不同、SSA 值名稱、屬性順序等)。像 llvm-canon 這樣的工具在這裡可能很有用。
• 測試崩潰/錯誤。ClangIR 不支援某些 C/C++ 結構，或者 LLVM 降低尚未實作。
• 測試通過。太棒了！

為了檢索上述資訊，學生需要變更 Clang 的測試基礎架構 (LIT 設定、腳本、測試、???)，以便更容易地重播啟用 ClangIR 的相同調用、與傳統管道結果進行比較或從測試中檢索特殊指示。

目前尚不清楚最佳方法是什麼，但預計希望被認真對待的提交提案應提出關於如何實現此目標的幾個可能想法，鼓勵與社群的其他成員進行事先討論。也希望學生與 ClangIR 社群互動、提交 github 問題、調查和/或變更失敗的 codegen 測試。

預期結果

1. 建置基礎架構以執行測試並收集結果。
2. 以可以放置在網頁上的方式呈現結果。
3. 為上述「FileCheck 失敗」類別的 50% 檔案問題或變更檢查行。目前只需要考慮以下子目錄

       clang/test/CodeGen
       clang/test/CodeGenCXX
       clang/test/CodeGenOpenCL
       clang/test/CodeGenCUDA
       

• 額外加分：尋找自動化/促進測試變更的方法，提出 PR 以修正 ClangIR 中的問題。

技能： 需要 Python、中級 C++ 程式設計技能和熟悉基本編譯器設計概念。LLVM IR、MLIR、Clang 或 ClangIR 程式設計的先前經驗是一個很大的加分項，但願意學習也是一種可能性。

專案規模： 大型

難度：中等

潛在導師： Bruno Cardoso Lopes Andy Kaylor

Discourse: 網址

描述： ClangIR 是 C 和 C++ 程式碼的新的、基於 MLIR 的中間表示法。它已在 LLVM 孵化器專案中開發，但目前正在進行將程式碼從孵化器遷移到主要 LLVM 儲存庫的工作。在移動程式碼時，必須更新程式碼以符合 LLVM 編碼標準和品質期望。此專案的目標是參與 ClangIR 上游化過程，並幫助改進程式碼和上游化過程。

ClangIR 專案旨在透過新增更緊密地模擬原始碼結構的抽象，保留比標準 LLVM IR 中可用的更多細節，來解鎖 C 和 C++ 程式碼的更好最佳化、分析和診斷的可能性。ClangIR 方言已經在使用 ClangIR 孵化器中可用的實作來解決實際問題，但我們需要將其移至主要 LLVM 儲存庫，以便向更廣泛的受眾提供此功能。

此專案將是一個獲得 MLIR 開發實務經驗的機會，重點是日常軟體工程紀律。參與者將與其他 LLVM 貢獻者並肩工作以實現共同目標，並在此過程中深入了解 ClangIR 方言。

預期結果

1. 將 ClangIR 對 C 和 C++ 語言功能的支援遷移到主要 LLVM 儲存庫中
2. 在遷移程式碼時提高程式碼品質
3. 提出改進遷移過程的方法

技能： 需要精通現代 C++ 程式設計和熟悉基本編譯器設計概念。LLVM IR、MLIR、Clang 或 ClangIR 程式設計的先前經驗是一個很大的加分項，但由於此專案的目標是獲得此類經驗，因此它不是先決條件。

專案規模： 中等到大型

難度：中等

潛在導師： Andy Kaylor Bruno Cardoso Lopes

Discourse: 網址

描述： Clang 靜態分析器 (CSA) 已經可以找到各種時間記憶體錯誤。這些檢查通常具有關於某些 API 行為的硬式編碼知識。例如，cplusplus.InnerPointer 檢查器知道 std::string::data 的語意。Clang 社群引入了一些生命週期註解，包括 [[clang::lifetimebound]] 和 [[clang::lifetime_capture_by(X)]]，並對 Clang 的預設警告進行了許多改進。不幸的是，編譯器的警告僅執行語句本機分析。CSA 能夠進行進階的跨程序分析。通用化現有的檢查 (如 cplusplus.InnerPointer) 可以使分析器在註解的程式碼中找到更多錯誤。一旦標準程式庫 被註解，這可能會變得更具影響力。

預期結果

1. 識別可以從 [[clang::lifetimebound]] 和 [[clang::lifetime_capture_by(X)]] 註解中受益的檢查。
2. 擴展這些檢查以支援這些註解。
3. 確保產生的錯誤報告品質高，診斷正確解釋分析器如何考慮這些註解。
4. 在真實世界的專案上驗證結果。
5. 可能會警告錯誤的註解 (延伸目標)。

技能： 需要中級 C++ 程式設計技能和熟悉基本編譯器設計概念。Clang 或 CSA 程式設計的先前經驗是一個很大的加分項，但願意學習也是一種可能性。

專案規模： 大型

難度：困難

潛在導師： Gabor Horvath Balazs Benics Daniel Domjan

Discourse: 網址

描述

目前沒有簡單的方法可以使用 C++20 模組來取得原始碼檔案集合並從中建置可執行檔。這使得難以建立使用 C++20 模組的簡單測試或小型程式，而無需先設定建置系統。此專案的目標是擴展 Clang 驅動程式中極其簡單的建置系統，以處理這些情況。

這可以透過使用 Clang 現有的掃描 C++20 模組的支援來完成，以發現已傳入的原始碼檔案之間的依賴關係，然後按該順序建置它們，在需要的地方傳入正確的 PCM 檔案。這也可以擴展為支援明確建置透過模組地圖檔案發現的 Clang 模組。

預期成果

以類似於以下方式調用 clang

clang -o program -std=c++20 main.cpp A.cppm B.cppm

已確認的導師及其聯絡方式

• Michael Spencer

所需技能

中級 C++ 知識；熟悉 C++ 程式碼的建置方式。熟悉 C++20 模組是一個優勢，但不是必需的。

專案規模

中等 (~175 小時)

專案難度

中等

Discourse: 網址

描述

未定義行為偵測器 (UBSan) 是 Clang 中用於尋找未定義行為 (例如，帶號整數溢位) 和有問題的 C/C++ 程式碼 (例如，無號整數溢位) 用途的有用編譯模式。UBSan 的預設版本使用僅在使用者空間中運作的編譯器執行階段 (例如，它在核心或嵌入式應用程式中無法運作)，並且被認為不夠安全，無法在生產環境中使用。為了處理這些其他環境，UBSan 提供了一種捕獲模式，該模式發射捕獲指令，立即停止應用程式，而不是調用通常診斷問題然後繼續執行的 UBSan 執行階段。

不幸的是，捕獲 UBSan 存在一些缺陷，使其難以使用。特別是

• Clang 會靜默忽略-fsanitize-trap=undefined標誌，當它在沒有-fsanitize=undefined的情況下傳遞時。此專案將修正此問題，作為「熱身任務」，以熟悉 Clang 程式碼庫。
• 當附加除錯器時遇到 UBSan 捕獲時，不方便找出 UBSan 捕獲的原因。對於 x86_64 和 arm64，某些資訊編碼在指令中，但解碼此資訊非常不方便。雖然可以教導 LLDB 查看指令並解碼含義，但這是脆弱的，因為它取決於未記錄的編譯器 ABI。相反，我們可以基於__builtin_verbose_trap工作來編碼除錯資訊內部的捕獲原因 (「捕獲原因」)。如果時間允許，我們也可以研究發射更精確的捕獲原因

預期成果

• 當-fsanitize-trap=undefined標誌單獨傳遞時，編譯器會靜默忽略它。目前，Clang 要求也傳遞-fsanitize-trap=標誌。應教導 Clang 警告此問題。
• 教導 Clang 在 UBSan 捕獲指令上的除錯資訊中發射 UBSan 捕獲原因，類似於__builtin_verbose_trap的工作方式。
• 確認 LLDB 能夠識別 UBSan 捕獲原因，並為此新增測試。
• 如果時間允許，我們應研究透過使用編譯器中可用的資訊來發射更精確的捕獲原因。我們可能希望實作類似於「Sema Diagnostic」的方法，在其中可以輕鬆地在編譯器內部建構捕獲原因字串。此任務更開放，並且可能在 UBSan 之外使用 (例如-fbounds-safety).

已確認的導師及其聯絡方式

• Dan Liew
• Michael Buch

所需技能

良好的 C++ 理解能力

期望的技能

• 熟悉 UBSan
• 熟悉 LLDB

專案規模

小型 (~90 小時)。但如果時間允許，可以擴展

專案難度

簡單。此專案對於 LLVM 初學者來說是不錯的選擇。請注意，「發射更精確的捕獲原因」部分更開放，因此其難度完全取決於申請人選擇的方向。

Discourse: 網址

專案描述： Clang-Doc 是一個 C/C++ 文件產生工具，作為 Doxygen 的替代方案而建立，並建立在 LibTooling 之上。此工作始於 2018 年，關鍵質量已於 2019 年落地，但開發在很大程度上一直停滯不前，主要是由於資源匱乏，直到去年開發作為一個成功的 Google 程式碼夏令營專案重新啟動。

該工具建立在 LibTooling 之上，並利用 Clang 解析器，該解析器支援解析文件註解中的 Doxygen 命令 (此支援也用於實作 Clang 的

-Wdocumentation

• 並非所有 Doxygen 命令都受支援，這限制了 Clang-Doc 的可用性。
• 並非所有 C/C++ 結構目前都已處理，最值得注意的是 C++20 功能，例如概念。
• Doxygen 1.8.0 版中引入的文件註解中的 Markdown 支援遺失。

預期結果： 此專案的目標是在 Clang 的文件解析器中實作遺失的功能，以及它們在 Clang-Doc 中的處理方式，以提高產生文件的品質。最終目標是讓 LLVM 專案開始使用 Clang-Doc 來產生其參考文件，但在我們可以做到這一點之前，我們需要確保所有必要的功能都已實作。

成功的提案不僅應側重於解決現有的限制，還應從其他文件工具 (例如 hdoc、standardese、subdoc 或 cppdocgen) 中汲取其他潛在改進的靈感。

在專案過程中，候選人將有機會獲得 LLVM 和 Clang 內部 (包括詞法分析器和解析器) 以及 C/C++ 語言的豐富經驗。

技能： 中級 C++ 知識；對編譯器和解析器感興趣。Clang/LibTooling 的先前經驗是一個加分項，但不是必需的。

專案規模： 中等或大型。

難度： 中等

已確認的導師： Petr Hosek、Paul Kirth

Discourse: 網址

專案描述： Clang 編譯器是 LLVM 編譯器基礎架構的一部分，支援多種語言，例如 C、C++、ObjC 和 ObjC++。 LLVM 和 Clang 的設計使其能夠作為函式庫使用，並促成了整個編譯器輔助工具生態系統的創建。 Clang 相對友善的程式碼庫以及 LLVM 中 JIT 基礎架構的進步，進一步推動了對不同 C++ 處理方法的研究，模糊了編譯時間和運行時間之間的界線。 挑戰包括增量編譯以及將編譯/連結時間最佳化融入更動態的環境中。 增量編譯管線透過建構不斷成長的翻譯單元，逐塊處理程式碼。 然後將程式碼降低到 LLVM IR 中，並隨後由 LLVM JIT 執行。 這種管線允許建立高效的直譯器。 直譯器實現了互動式探索，並使 C++ 語言更加使用者友善。 Clang-Repl 就是一個例子。

預期成果： 本專案旨在開發一個穩健的機制，透過動態識別和載入適當的共享物件或靜態封存檔來解決遺失符號的問題。 此外，它將探索基於執行設定檔調整符號的用例，從而顯著提高效能，最佳化即時編譯和動態執行環境的效率。

技能： C++ 中等程度知識，理解 LLVM 和 LLVM JIT，尤其如此

專案規模：中型或大型。

難度： 中等

已確認指導教授： Vassil Vassilev

討論區： 網址

描述

Enzyme 需要關於型別記憶體佈局的良好資訊。 LLVM-IR 是刻意不透明的，例如 `&f32` 和 `&f64` 都具有 LLVM-IR 型別 `ptr`。 Enzyme 通常能夠透過使用情況分析來推斷底層型別（例如 f32 與 f64），但該過程緩慢，並且在某些情況下可能會失敗。 為了使自動微分更加穩健，我們應該將 MIR 或 THIR 型別資訊降低到 LLVM-IR metadata 中。 此分析是遞迴的，例如 `&[T]` 是一個胖指標，因此在 LLVM-IR 中將表示為 (ptr, int) 對。 在這種情況下，演算法也應該遞迴地分析 `T` 並為其產生 metadata。

此處的 函數 可以擴展為從 rust 的中階 IR (MIR) 產生 metadata。 解析器的原型已在 此處 實作，可用於啟發靈感。 我們想要產生的 metadata 的各種 LLVM-IR 範例可以在 此 測試資料夾中找到。 尋找 ` {[-1]:Pointer, [-1,0]:Float@float}` 風格的註解。

線上編譯器 Explorer 分支可用於觸發相關錯誤，從「無法推斷 X 的型別」開始。

預期成果

參與者應找到並選擇一些有趣的測試案例，在這些案例中，Enzyme 要么由於型別資訊不足而無法區分範例，要么花費過長的時間（例如，比編譯不含自動微分的程式碼慢 20 倍以上）。 在第二種情況下，應使用效能分析器來驗證 Enzyme 是否由於型別分析而導致編譯時間過長。 然後，參與者應編寫（或稍後擴展）型別解析器以產生正確的 metadata，以便 Enzyme 可以處理新的測試案例。 LIT 測試案例應新增至 rust 編譯器，以避免進一步的迴歸。

目前未正確處理的程式碼範例可以在專案提案階段進行討論。

已確認的導師及其聯絡方式

• Manuel Drehwald
• Oli Scherer
• Johannes Doerfert

所需技能

Rust 和 C++ 中等程度知識； 熟悉效能分析器或 LLVM metadata 是一個優勢，但非必要。

專案規模

中等 (~175 小時)

專案難度

中等

討論區： 網址

描述： 目前，每個想要支援呼叫 C 程式碼 (FFI) 的基於 LLVM 的前端都需要重新實作大量複雜的呼叫 ABI 處理。 本專案的目標是引入一個 LLVM ABI 函式庫，該函式庫可以在不同的前端（包括 Clang）之間重複使用。 有關動機的更多詳細資訊以及設計的廣泛概述，請參閱 相應的 RFC。

專案的初始階段將是實作一個原型，該原型至少可以處理 x86_64 System V ABI。 這將涉及實作 ABI 型別系統、將 Clang 型別映射到 ABI 型別，以及將至少一部分 X86 ABIInfo 實作從 Clang 移至新的 ABI 函式庫。 這是為了證明一般可行性、找出設計問題並分析編譯時間的影響。

假設原型的結果是正面的，下一步將是透過將其拆分為更小的 PR 來向上游實作。 最後，可以擴展實作以涵蓋其他目標，最終完全刪除 Clang 的 ABI 處理程式碼。

預期成果： 最低限度的成果是 x86_64 ABI 的原型。 最大限度的成果是對所有目標的完全向上游支援。 預期的成果介於兩者之間。

技能： C++ 中等程度知識。 熟悉 LLVM 是一個優勢，但非必要。

專案規模： 大型

難度： 困難

已確認指導教授： Nikita Popov

討論區： 網址

描述： 由於缺乏表示原始記憶體的方式，LLVM IR 無法正確表示 memcpy、memcmp 等的實作。 本專案旨在向 LLVM IR 新增一個新的「byte」型別，以表示原始記憶體。

除了新增新的型別之外，該專案還涉及變更 clang 以將 chars 降級為新的 b8 型別而不是 i8，修復記憶體內建函數的不正確降級，並追蹤效能迴歸。

已經有一個針對舊版本 LLVM 的 byte 型別的 原型 實作。 更多資訊請參閱 此處。

預期成果： 最低限度的成果是將現有的原型移植到目前的 LLVM，修復所有已知的錯誤最佳化，新增對 Alive2 的 byte 型別的支援，以及效能分析。

技能： C++ 中等程度知識，熟悉 LLVM、效能分析。

專案規模： 大型

難度： 困難

已確認指導教授： Nuno Lopes

討論區： 網址

描述： LLVM 透過 remarks、效能分析或執行階段偵錯註解（例如，LIBOMPTARGET_INFO=-1）提供不同的資訊。 然而，隨著專案的增加，使用者很難剖析這些資訊。 例如，在建構大型專案時，很難收集所有這些資料、將其視覺化並從中學習。

目前，某些資訊（例如，編譯 remarks）可以 JSON 格式匯出。 我們想要建立一個工具來視覺化、彙總和總結資訊。 為了協助加速器開發，我們將從卸載專案開始作為主要候選專案。

類似的工具（例如 opt-viewer）可以用作參考和起點。

預期成果： 預期的成果是一個工具（例如，以編譯器封裝器（如 ccache）的形式），它將允許以 JSON 格式轉儲所有編譯器產生的資訊，並將其組織在專案結構中。

該工具應產生基於 HTML 的報告，以協助視覺化 remarks。 我們設想一個小型用戶端-伺服器應用程式，使用 Python 生成一個本機伺服器作為視覺化的前端。 伺服器將公開不同的報告，並執行早期分析和彙總。

此外，該工具的設計應使其在未來能夠分析 remarks，從而為開發人員提供通用指南（例如，顯示最常見的 remark、使用 LLM 模型來解釋操作等）。 用戶端（HTML 檢視器）將顯示彙總的資料、內嵌 remarks、效能分析資訊等。 我們不期望該專案在 GSoC 結束時具備所有功能，但可以作為未來成長的基礎。

特別是，本專案的成果應該是

• 與指導教授一起協助設計編譯器封裝器、資料儲存層和用戶端/伺服器基礎架構。 這包括伺服器 API。 此任務的成果是一份設計文件（類似於 RFC）。
• 建立一個編譯器封裝器，將不同的資訊以 JSON 格式轉儲到資料儲存層（例如，資料夾）中。
• 建立一個簡單的伺服器層，向前端公開後端 API。 Python 是正確的方法，但我們歡迎其他與 LLVM 專案一致的建議。 我們希望避免依賴外部專案（例如 Flask），以避免向 LLVM 專案新增更多相依性。
• 建立一個簡單的用戶端視覺化工具，該工具在未來可以擴展以顯示更多報告。

指導教授： @shiltian、 @jdoerfert、 @josemonsalve2

必要/期望的技能

• 基本理解 LLVM 編譯器，能夠從編譯器產生編譯器 remarks、效能分析資料和其他資訊。
• 精通 Python 和 C++。
• 全端網頁開發。

專案規模： 大型

難度： 簡單

討論區連結： [GSoC][Offload]LLVM 卸載編譯器 Remarks 視覺化工具提案

Google Summer of Code 2024 對於 LLVM 專案來說又是成功的一年。 有關已接受和已完成專案的列表，請查看 Google Summer of Code 網站。

歡迎有潛力的 Google Summer of Code 2024 學生！ 本文件是您尋找 LLVM、Clang 和其他相關子專案中有趣且重要專案的起點。 此專案列表不僅是為 Google Summer of Code 開發的，也是真正需要開發人員參與且對 LLVM 社群非常有益的開放專案。

我們鼓勵您瀏覽此列表，看看哪些專案讓您感到興奮，並與您的技能組合非常吻合。我們也歡迎未在此列表中的提案。有關 GSoC 的更多資訊和討論，請參閱 discourse 。如果您對特定專案有疑問，請在 discourse 中找到相關條目，查看先前的討論並提問。如果沒有此類條目，或者您想提出想法，請建立一個新條目。來自社群的回饋是您的提案被考慮並希望被接受的要求。

LLVM 專案已參與 Google Summer of Code 多年，並取得了一些非常成功的專案。 我們希望今年也不例外，並期待收到您的提案。 有關如何提交提案的資訊，請造訪 Google Summer of Code 主要 網站。

專案描述： LLVM 的許多單元測試都是從較大的測試中自動縮減而來的。 上一代縮減工具到處都使用 undef 和 poison 作為佔位符，並且還引入了未定義行為 (UB)。 具有 UB 的測試是不理想的，因為 1) 它們很脆弱，因為未來編譯器可能會開始更積極地最佳化並破壞測試，以及 2) 它破壞了翻譯驗證工具，例如 Alive2（因為將始終為 UB 的函數翻譯成任何內容都是正確的）。
主要步驟包括

1. 將已知模式（例如，undef/poison 上的分支、具有無效指標的記憶體存取等）替換為非 UB 模式。
2. 使用 Alive2 偵測更多模式（透過搜尋始終為 UB 的測試）。
3. 報告 Alive2 在刪除 UB 時發現的任何 LLVM 錯誤。

預期成果： 大多數 LLVM 的單元測試將沒有 UB。

技能： 需要腳本編寫（Python 或 PHP）經驗。 鼓勵具有正規表示式經驗。

專案規模： 中等或大型。

難度： 中等

已確認指導教授： Nuno Lopes

討論區： 網址

專案描述： LLVM 中描述 SPIR-V 指令集的現有檔案是手動建立的，並且並不總是完整或最新的。 每當需要將新指令新增到 SPIR-V 後端時，都必須修改該檔案。 此外，由於它不是以系統化的方式建立的，因此 SPIR-V 規範中指令的描述方式與 TableGen 檔案中的宣告方式之間通常存在細微的差異。 由於 SPIR-V 後端開發人員在開發新功能時經常使用規範作為參考，因此在規範與 TableGen 記錄之間建立一致的映射將簡化開發。 本專案建議建立一個腳本，該腳本能夠根據 KhronosGroup/SPIRV-Headers 儲存庫中提供的 JSON 文法產生一個完整的 TableGen 檔案，該檔案描述 SPIR-V 指令集，並更新 SPIR-V 後端程式碼以使用新的定義。 將 JSON 文法轉換為 TableGen 的具體方法由申請人自行決定，但是，應將其檢入 LLVM 儲存庫，並附上詳細的文件說明以複製轉換過程，以便未來的維護人員能夠在文法變更時重新產生檔案。 請注意，文法本身應保留在樹狀結構之外，在其現有的獨立儲存庫中。

預期結果

• TableGen 中 SPIR-V 指令集的定義將替換為自動產生的定義。
• 編寫了一個腳本和文件，支援根據 SPIR-V 指令集的 JSON 文法，根據需要重新產生定義。
• SPIR-V 後端中 SPIR-V 指令集的使用已更新為使用新的自動產生定義。

技能： 腳本編寫經驗和 C++ 中等程度知識。 之前具有 LLVM/TableGen 經驗是一個優勢，但非必要。

專案規模： 中型（175 小時）

已確認指導教授： Natalie Chouinard、 Nathan Gauër

討論區： 網址

專案描述： LLVM 位元流檔案格式用於序列化中介編譯器產物，例如 LLVM IR 或 Clang 模組。 在某些情況下，多個位元流檔案儲存相同的資訊，這種重複導致儲存需求增加。

本專案旨在將 LLVM CAS 函式庫整合到 LLVM 位元流檔案格式中。 如果我們將位元流檔案中經常重複的部分分解為單獨的 CAS 物件，我們可以用對規範 CAS 物件的小參考替換所有副本，從而節省儲存空間。

本專案的主要動機用例是依賴性掃描器，它為「隱式發現、顯式建構」的 Clang 模組提供支援。 在實際情況中，即使是區塊層級的粗略去重複也可以將掃描模組快取的大小減半。

預期成果： 有一種方法可以配置 LLVM 位元流寫入器/讀取器以使用 CAS 作為後備儲存。

技能： C++ 中等程度知識，對資料序列化有一定的熟悉度，自我激勵。

專案規模： 中型或大型

已確認指導教授： Jan Svoboda、 Steven Wu

討論區： 網址

專案描述： 3 向比較 傳回值 -1、0 或 1，具體取決於值比較是較小、相等還是較大。 它們在 C++ 中透過太空船運算子 (operator<=>) 公開，在 Rust 中透過 PartialOrd 和 Ord 特徵公開。 目前，這種比較在某些情況下會產生次佳的程式碼產生和最佳化結果。

本專案的目標是透過實作新的 3 向比較內建函數來解決這些最佳化問題，如 [RFC] 新增 3 向比較內建函數 中所述。 實作步驟大致如下

1. 將內建函數新增到 LLVM IR。
2. 在 SelectionDAG 和 GlobalISel 中實作合法化/擴充支援。
3. 在 ConstantFolding、InstSimplify、InstCombine、CorrelatedValuePropagation、IndVarSimplify、ConstraintElimination、IPSCCP 和其他相關轉換中實作最佳化支援。
4. 透過 InstCombine 正規化或 clang/rustc 中的直接發射來使用內建函數。

預期成果： 後端和最重要的最佳化傳遞中對內建函數的支援。 理想情況下，從前端開始完全整合。

技能： C++ 中等程度知識

專案規模： 中型或大型

難度： 中等

已確認指導教授： Nikita Popov、 Dhruv Chawla

討論區： 網址

專案描述： llvm.org 網站是關於 LLVM 專案資訊的中心樞紐，涵蓋專案詳細資訊、當前事件和相關資源。 隨著時間的推移，網站已經有機地發展，促使需要重新設計以增強其現代性、結構和易於維護性。

本專案的目標是建立一個現代且連貫的靜態網站，以反映 LLVM.org 的本質。 此重新設計旨在改善導航、分類、內容可發現性、行動裝置支援、可存取性和整體可用性。 鑑於該網站在社群中的關鍵作用，將努力與社群成員互動，就擬議的變更尋求共識。

預期成果： 一個現代、外觀連貫的網站，可以吸引新的潛在使用者，並透過更好的導航、分類、內容可發現性和整體可用性來增強現有社群的能力。 由於該網站是一個關鍵基礎架構，並且大多數社群成員都會有意見，因此本專案應嘗試與社群互動，建立社群對所採取步驟的共識。 建議方法

• 對現有網站進行全面的內容稽核。
• 選擇適當的技術，最好是 Hugo 或 Jekyll 等靜態網站產生器。
• 倡導資料和視覺化的分離，利用 YAML 和 Markdown 等格式來促進內容管理，而無需直接進行 HTML 編碼。
• 展示新網站的三個設計模型，促進公開討論，並允許感興趣的各方提出替代方案的時間。
• 實作選定的設計，並納入社群的寶貴意見回饋。
• 與內容建立者協作，以根據需要整合或更新內容。

技能： 靜態網站產生器網頁開發領域的知識。 HTML、CSS、Bootstrap 和 Markdown 方面的知識。 耐心和自我激勵。

難度： 困難

專案規模： 大型

已確認指導教授： Tanya Lattner、 Vassil Vassilev

討論區： 網址

專案描述： Clang 編譯器是 LLVM 編譯器基礎架構的一部分，支援多種語言，例如 C、C++、ObjC 和 ObjC++。 LLVM 和 Clang 的設計使其能夠作為函式庫使用，並促成了整個編譯器輔助工具生態系統的創建。 Clang 相對友善的程式碼庫以及 LLVM 中 JIT 基礎架構的進步，進一步推動了對不同 C++ 處理方法的研究，模糊了編譯時間和運行時間之間的界線。 挑戰包括增量編譯以及將編譯/連結時間最佳化融入更動態的環境中。

增量編譯管線透過建構不斷成長的翻譯單元，逐塊處理程式碼。 然後將程式碼降低到 LLVM IR 中，並隨後由 LLVM JIT 執行。 這種管線允許建立高效的直譯器。 直譯器實現了互動式探索，並使 C++ 語言更加使用者友善。 Clang-Repl 就是一個例子。

Clang-Repl 在同一個進程中使用 Orcv2 JIT 基礎架構。 這種設計高效且易於實作，但存在兩個重大缺點。 首先，它不能用於資源不足以託管整個基礎架構的裝置中，例如 arduino due（有關更多詳細資訊，請參閱此 演講）。 其次，使用者程式碼中的崩潰意味著整個進程崩潰，從而妨礙了整體可靠性和易用性。

本專案旨在將 Clang-Repl 移至進程外執行模型，以解決這兩個問題。

預期成果： 實作 Clang-Repl 的語句的進程外執行； 證明 Clang-Repl 可以支援 ez-clang 的一些用例； 研究在崩潰時重新啟動/繼續會話的方法； 作為一個延伸目標，設計一個用於崩潰恢復的多功能可靠性方法；

技能： C++ 中等程度知識，理解 LLVM 和 LLVM JIT，尤其如此

專案規模：中型或大型。

難度： 中等

已確認指導教授： Vassil Vassilev、

討論區： 網址

專案描述： Clang 編譯器是 LLVM 編譯器基礎架構的一部分，支援多種語言，例如 C、C++、ObjC 和 ObjC++。 LLVM 和 Clang 的設計允許使用外掛程式 [1] 擴展編譯器。 外掛程式使得在編譯期間運行額外的使用者定義動作成為可能。 由於 Windows 平台的一些特殊性，Unix 和 Darwin 上支援外掛程式，但在 Windows 上不受支援。

本專案將使參與者接觸到 LLVM 程式碼庫的廣泛橫截面。 它涉及探索 API 介面、將介面分類為公共或私有，以及將該資訊註解到 API 宣告中。 它還將使參與者接觸到不同平台的詳細資訊和差異，因為這項工作是跨平台的（Windows、Linux、Darwin、BSD 等）。 由此產生的變更將改善 Linux 和 Windows 上的 LLVM，同時在 Windows 上啟用新功能。

預期成果： 本專案旨在使 clang -fplugin=windows/plugin.dll 工作。 實作方法應擴展工作原型 [3] 並擴展註解工具 [4]。 成功的候選人應準備好參加每週會議、進行簡報並根據要求準備部落格文章。

進一步閱讀
[1] https://clang.llvm.org/docs/ClangPlugins.html
[2] https://discourse.llvm.org/t/clang-plugins-on-windows
[3] https://github.com/llvm/llvm-project/pull/67502
[4] https://github.com/compnerd/ids

技能： C++ 中等程度知識，具有 Windows 及其編譯和連結模型方面的經驗。

專案規模：中型或大型。

難度： 中等

已確認指導教授： Vassil Vassilev、 Saleem Abdulrasool

討論區： 網址

專案描述： Clang 與任何 C++ 編譯器一樣，線性地解析字元序列。 線性字元序列然後在降低為機器碼之前轉換為 token 和 AST。 在許多情況下，終端使用者程式碼僅使用整個翻譯單元中 C++ 實體的一小部分，但使用者仍然要為編譯所有冗餘付出代價。

本專案建議在使用時而不是急切地處理繁重的編譯 C++ 實體。 Clang 的 CodeGen 已經採用了這種方法，它允許 Clang 僅為正在使用的內容產生程式碼。 預計按需編譯將顯著減少編譯峰值記憶體並縮短稀疏使用其內容的翻譯單元的編譯時間。 此外，這將對互動式 C++ 產生重大影響，其中標頭包含本質上變為空操作，並且實體將僅按需解析。

Cling 直譯器實作了一個非常幼稚但高效的跨翻譯單元延遲編譯最佳化，該最佳化在高能物理領域的數百個函式庫中進行擴展。

// A.h
#include <string>
#include <vector>
template <class T, class U = int> struct AStruct {
  void doIt() { /*...*/ }
  const char* data;
  // ...
};

template<class T, class U = AStruct<T>>
inline void freeFunction() { /* ... */ }
inline void doit(unsigned N = 1) { /* ... */ }

// Main.cpp
#include "A.h"
int main() {
  doit();
  return 0;
}
    

// A.h.index
namespace std{inline namespace __1{template <class _Tp, class _Allocator> class __attribute__((annotate("$clingAutoload$vector")))  __attribute__((annotate("$clingAutoload$A.h")))  __vector_base;
  }}
...
template <class T, class U = int> struct __attribute__((annotate("$clingAutoload$A.h"))) AStruct;
    

預期結果

• 非模板化函數的按需編譯的設計和實作
• 支援非模板化結構和類別
• 在相關程式碼庫上運行效能基準測試並準備報告
• 準備社群 RFC 文件
• [延伸目標] 支援模板

進一步閱讀
[1] https://github.com/root-project/root/blob/master/README/README.CXXMODULES.md#header-parsing-in-root
[2] https://github.com/llvm/llvm-project/commit/b9fa99649bc99
[3] https://github.com/llvm/llvm-project/commit/0f192e89405ce

技能： C++ 知識，更深入地了解 Clang 的工作原理，Clang AST 和 Preprocessor 的知識。

專案規模：大型

難度： 困難

已確認指導教授： Vassil Vassilev、 Matheus Izvekov

討論區： 網址

專案描述： Clang-Doc 是一個 C/C++ 文件產生工具，作為 Doxygen 的替代品而建立，並建立在 LibTooling 之上。 這項工作始於 2018 年，關鍵群眾在 2019 年登陸，但此後的開發基本上處於休眠狀態，主要是由於資源匱乏。

該工具目前可以產生 Markdown 和 HTML 格式的文件，但該工具存在一些結構性問題，難以使用，產生的文件存在可用性問題，並且缺少幾個關鍵功能

• 並非所有 C/C++ 建構目前都由 Markdown 和 HTML 發射器處理，從而限制了該工具的可用性。
• 產生的 HTML 輸出無法隨著程式碼庫的大小而擴展，這使得它對於較大的 C/C++ 專案不可用。
• 實作並不總是使用最有效或最合適的資料結構，這會導致正確性和效能問題。
• 存在許多重複的樣板程式碼，可以使用模板和輔助函數來改進。

預期成果： 本專案的目標是解決現有的缺點並提高 Clang-Doc 的可用性，使其達到可用於為 LLVM 等大型專案產生文件的程度。 理想的結果是 LLVM 專案將使用 Clang-Doc 來產生其 參考文件。

成功的提案不僅應關注解決現有的限制，還應從其他類似工具（例如 hdoc、 standardese、 subdoc 或 cppdocgen）中汲取其他潛在改進的靈感。

技能： 具有網頁技術（HTML、CSS、JS）的經驗和 C++ 中等程度知識。 之前具有 Clang/LibTooling 經驗是一個優勢，但非必要。

專案規模： 中等或大型。

難度： 中等

已確認的導師： Petr Hosek、Paul Kirth

討論區： 網址

描述

使用來自除錯資訊的變數位置資訊，以來源變數的位置和生命週期註解 LLDB 的反組譯器 (和 `register read`) 輸出。豐富的反組譯器輸出應公開為結構化資料，並透過 LLDB 的腳本 API 提供，以便可以在此基礎上建置更多工具。在終端機中，LLDB 應將註解呈現為文字。

預期成果

frame #0: 0x0000000100000f80 a.out`main(argc=1, argv=0x00007ff7bfeff1d8) at demo.c:4:10 [opt]
  1   void puts(const char*);
  2   int main(int argc, char **argv) {
  3    for (int i = 0; i < argc; ++i)
→ 4      puts(argv[i]);
  5    return 0;
  6   }
(lldb) disassemble
a.out`main:
...
  0x100000f71 <+17>: movl  %edi, %r14d
  0x100000f74 <+20>: xorl  %r15d, %r15d
  0x100000f77 <+23>: nopw  (%rax,%rax)
→  0x100000f80 <+32>: movq  (%rbx,%r15,8), %rdi
  0x100000f84 <+36>: callq 0x100000f9e ; symbol stub for: puts
  0x100000f89 <+41>: incq  %r15
  0x100000f8c <+44>: cmpq  %r15, %r14
  0x100000f8f <+47>: jne 0x100000f80 ; <+32> at demo.c:4:10
  0x100000f91 <+49>: addq  $0x8, %rsp
  0x100000f95 <+53>: popq  %rbx
...

使用 LLDB 也可存取的除錯資訊 (觀察來源變數 i 如何從 [0x100000f77+slide) 開始在 r15 中)

$ dwarfdump demo.dSYM --name  i
demo.dSYM/Contents/Resources/DWARF/demo: file format Mach-O 64-bit x86-64
0x00000076: DW_TAG_variable
 DW_AT_location (0x00000098:
 [0x0000000100000f60, 0x0000000100000f77): DW_OP_consts +0, DW_OP_stack_value
 [0x0000000100000f77, 0x0000000100000f91): DW_OP_reg15 R15)
 DW_AT_name ("i")
 DW_AT_decl_file ("/tmp/t.c")
 DW_AT_decl_line (3)
 DW_AT_type (0x000000b2 "int")

(lldb) disassemble
a.out`main:
...                                                               ; i=0
  0x100000f74 <+20>: xorl  %r15d, %r15d                           ; i=r15
  0x100000f77 <+23>: nopw  (%rax,%rax)                            ; |
→  0x100000f80 <+32>: movq  (%rbx,%r15,8), %rdi                   ; |
  0x100000f84 <+36>: callq 0x100000f9e ; symbol stub for: puts    ; |
  0x100000f89 <+41>: incq  %r15                                   ; |
  0x100000f8c <+44>: cmpq  %r15, %r14                             ; |
  0x100000f8f <+47>: jne 0x100000f80 ; <+32> at t.c:4:10          ; |
  0x100000f91 <+49>: addq  $0x8, %rsp                             ; i=undef
  0x100000f95 <+53>: popq  %rbx

目標是為一組明確的案例產生像這樣的輸出，例如，常數或完全在暫存器中的變數。

已確認的導師及其聯絡方式

• Adrian Prantl aprantl@apple.com (主要聯絡人)
• Jonas Devlieghere jdevlieghere@apple.com

所需/期望的技能

必要條件

• 良好的 C++ 理解能力
• 熟悉在終端機上使用除錯器
• 需要熟悉上面範例中提及的所有概念
• 需要充分理解至少一種機器碼的組合語言 (x86_64 或 AArch64)。

期望條件

• 編譯器知識，包括資料流和控制流分析，是加分項。
• 能夠瀏覽除錯資訊 (DWARF) 是加分項。

專案規模。

中等 (~175 小時)

如果可能，給出簡單、中等或困難的評級

困難

Discourse: 網址

描述

LLVM-reduce 和類似工具執行增量偵錯，但如果存在許多隱式約束，並且違規很容易導致類似於要隔離的原因的錯誤，則它們不太有用。 本專案是關於開發 GPU 感知版本，特別是對於執行時間錯誤，該版本可以與 LLVM/OpenMP GPU 記錄和重播或簡單的 GPU 載入器腳本結合使用，以更有效和高效地最小化 GPU 測試案例。

預期成果

一種減少 GPU 錯誤而不遺失原始錯誤的工具。 或者，其他屬性可以是縮減的重點，而不僅僅是錯誤。

已確認的導師及其聯絡方式

• Parasyris，Konstantinos parasyris1@llnl.gov
• Johannes Doerfert jdoerfert@llnl.gov

所需/期望的技能

必要條件

• 良好的 C++ 理解能力
• 熟悉 GPU 和 LLVM-IR

期望條件

• 編譯器知識，包括資料流和控制流分析，是加分項。
• 具有偵錯和錯誤縮減技術（llvm-reduce）的經驗會有所幫助

專案規模。

中等

如果可能，給出簡單、中等或困難的評級

中等

討論區： 網址

描述

現代 C++ 將並行演算法定義為標準函式庫的一部分，例如 `std::transform_reduce(std::execution::par_unseq, vec.begin(), vec.end(), 0, std::plus, …)`。 在這個專案中，我們希望擴展使用 OpenMP 的實作，包括 GPU 卸載（在合理的情況下）。 雖然某些演算法可能適合透過純粹的（封裝器）運行時解決方案進行 GPU 卸載，但我們知道其他演算法，尤其是那些具有使用者提供的函子的演算法，也將需要靜態程式分析和潛在的轉換以進行額外的資料管理。 該專案的目標是探索不同的演算法以及我們擁有的選項，以在主機以及加速器裝置（尤其是 GPU）上透過 OpenMP 自動執行它們。

預期成果

改進 libcxx 中卸載的原型支援。 針對其他卸載方法進行評估，並記錄遺失的部分和缺點。

已確認的導師及其聯絡方式

• Johannes Doerfert jdoerfert@llnl.gov
• Tom Scogland scogland1@llnl.gov
• Tom Deakin tom.deakin@bristol.ac.uk

所需/期望的技能

必要條件

• 對 C++ 和 C++ 標準演算法有良好的理解
• 熟悉 GPU 和（OpenMP）卸載

期望條件

• 具有 libcxx（開發）經驗。
• 具有偵錯和效能分析 GPU 程式碼的經驗。

專案規模。

大型

如果可能，給出簡單、中等或困難的評級

中等

討論區： 網址

描述

LLVM 有很多閾值和標誌來避免「成本高昂的情況」。 但是，尚不清楚這些閾值是否有用、它們的值是否合理以及它們的真正影響是什麼。 由於閾值很多，我們無法進行簡單的窮舉搜尋。 在一些原型工作中，我們引入了一個 C++ 類別，它可以替換硬編碼的值並提供對閾值的控制，例如，您可以透過命令列標誌將遞迴限制從硬編碼的「6」增加到不同的數字。 在這個專案中，我們想要探索閾值、它們何時被命中、它們被命中意味著什麼、我們應該如何選擇它們的值，以及我們是否需要不同的「設定檔」。

預期成果

關於 LLVM 程式碼庫內各種閾值影響的統計證據，包括編譯時間變更、對轉換的影響和效能測量。

已確認的導師及其聯絡方式

• Jan Hueckelheim jhueckelheim@anl.gov
• Johannes Doerfert jdoerfert@llnl.gov
• William Moses wmoses@mit.edu

所需/期望的技能

必要條件

• 統計推理的分析技能與知識

期望條件

• 良好理解 LLVM 程式碼庫與最佳化流程

專案規模。

中等

如果可能，給出簡單、中等或困難的評級

簡單

討論區： URL

描述

我們已開始著手開發以 GPU 為目標的 libc 函式庫。這將允許使用者在 GPU 上執行時呼叫如 malloc 或 memcpy 等函式。然而，這些實作的功能性與效能至關重要。此專案的目標是針對 GPU 上特定 libc 函式的實作進行基準測試。工作內容將包括編寫基準測試以測試目前的實作，以及編寫更佳化的實作。

預期成果

libc 函式的深入效能分析。GPU 到 CPU 遠端程序呼叫的額外負擔。「libc」函式的更佳化實作。

已確認的導師及其聯絡方式

• Joseph Huber joseph.huber@amd.com
• Johannes Doerfert jdoerfert@llnl.gov

所需/期望的技能

必要條件

• 分析技能與對 GPU 架構的理解

期望條件

• libc 工具程式的使用經驗

專案規模。

小

如果可能，給出簡單、中等或困難的評級

簡單

討論區： URL

描述

GPU First 是一種方法論與框架，可使任何現有的主機程式碼在 GPU 上執行整個程式，而無需使用者進行任何修改。此專案的目標有兩個： 1) 將 主機程式碼移植以處理與新外掛程式的 RPC，並使用 GPU LibC 專案中引入的主機 RPC 框架重寫它。 2) 探索在單一 GPU 甚至多個 GPU 上，多個執行緒區塊之間對 MPI 的支援。

預期成果

更有效率的 GPU First 框架，可以支援 NVIDIA 和 AMD GPU。可選擇性地將此框架向上游提交。

已確認的導師及其聯絡方式

• Shilei Tian i@tianshilei.me
• Johannes Doerfert jdoerfert@llnl.gov
• Joseph Huber joseph.huber@amd.com

所需/期望的技能

必要條件

• 良好理解 C++ 與 GPU 架構
• 熟悉 GPU 和 LLVM IR

期望條件

• 良好理解 LLVM 程式碼庫與 OpenMP 目標卸載

專案規模。

中等

如果可能，給出簡單、中等或困難的評級

中等

討論區： URL

專案描述： 諸如 SYCL、OpenMP 和 OpenACC 等異質程式設計模型，協助開發人員將計算密集型核心程式卸載到 GPU 和其他加速器。MLIR 有望為下一代異質程式設計模型的編譯器，解鎖新的高階最佳化和更好的程式碼生成。然而，具備穩健的 MLIR 發射 C/C++ 前端是這些努力的先決條件。

ClangIR (CIR) 專案旨在為 Clang 建立新的中介表示法 (IR)。ClangIR 建構於 MLIR 之上，為 Clang 中基於 C/C++ 的語言提供方言，以及從 Clang AST 發射它的必要基礎架構，以及通往 LLVM-IR 方言的降低路徑。在過去一年中，ClangIR 已發展成為成熟的孵化器專案，並且最近關於將其向上游提交到 LLVM monorepo 的 RFC 已獲得正面評論和社群支持。

此 GSoC 專案的總體目標是識別並實作 ClangIR 中缺少的特性，以使其能夠將 OpenCL C 語言中的 GPU 核心程式編譯為 SPIR-V 目標的 LLVM-IR。OpenCL 到 SPIR-V 的流程是此專案的絕佳環境，因為 a) 它在 Clang 中已受到支援，且 b) OpenCL 基於工作項目和工作組的程式設計模型仍然很好地捕捉了現代 GPU 架構。貢獻者將擴展 AST 訪問器、方言和 LLVM-IR 降低，以新增對多個位址空間、向量和自訂浮點類型，以及 spir_kernel 和 spir_func 呼叫慣例的支援。

此項工作的良好起點是 Polybench-GPU 基準測試套件。它包含常見演算法的獨立小型到中型 OpenCL 實作。我們預期只有裝置程式碼 (*.cl 檔案) 會透過 ClangIR 編譯。Clang 中現有的 OpenCL 支援可用於建立具有參考 LLVM-IR 輸出的 lit 測試，以引導開發。或者，Polybench 中的內建結果驗證和時間測量也可用於評估生成程式碼的正確性和品質。

預期成果： Polybench-GPU 的 2DCONV、GEMM 和 CORR OpenCL 核心程式可以使用 ClangIR 編譯為 SPIR-V 的 LLVM-IR。

技能： 需要中級 C++ 程式設計技能和對基本編譯器設計概念的熟悉度。具備 LLVM IR、MLIR、Clang 或 GPU 程式設計的先前經驗會是很大的加分，但學習意願也是一種可能性。

專案規模： 大型

難度： 中等

已確認指導老師： Julian Oppermann、Victor Lomüller、Bruno Cardoso Lopes

討論區： URL

描述

半精度是一種 IEEE 754 浮點格式，近年來已廣泛使用，尤其是在機器學習和 AI 領域。它已在最新的 C23 標準中標準化為 _Float16，使其支援程度與 float 或 double 資料類型相同。此專案的目標是在 LLVM libc 函式庫中實作 C23 半精度數學函式。

預期結果

• 正確設定產生的標頭，以便類型和函式可以與各種編譯器 (+版本) 和架構一起使用。
• 實作支援半精度資料類型的通用基本數學運算，這些運算可在支援的架構上運作：x86_64、arm (32 + 64)、risc-v (32 + 64) 和 GPU。
• 盡可能使用編譯器內建函數或特殊硬體指令來實作特化，以提高其效能。
• 如果時間允許，我們可以開始研究用於半精度的更高階數學函式。

技能

需要中級 C++ 程式設計技能和對基本編譯器設計概念的熟悉度。具備 LLVM IR、MLIR、Clang 或 GPU 程式設計的先前經驗會是很大的加分，但學習意願也是一種可能性。

專案規模： 大型

難度： 簡單/中等

已確認指導老師： Tue Ly、Joseph Huber、

討論區： URL

Google Summer of Code 2023 對於 LLVM 專案來說非常成功。如需已接受和已完成專案的清單，請參閱 Google Summer of Code 網站。

專案描述： 在即時編譯器中，我們通常選擇較低的最佳化等級，以盡量減少編譯時間並改善啟動時間和延遲，然而，有些函式 (我們稱之為熱門函式) 使用頻率非常高，對於這些函式，更深入的最佳化是值得的。一般而言，熱門函式只能在執行階段識別 (不同的輸入將導致不同的函式變成熱門函式)，因此重新最佳化專案的目標是建構基礎架構，以 (1) 在執行階段偵測熱門函式，以及 (2) 以更高的最佳化等級再次編譯它們，因此稱為「重新最佳化」。

對於這個問題的兩個部分，有許多可能的方法。例如，熱門函式可以透過取樣、使用現有的效能分析基礎架構或實作自訂檢測來識別。重新最佳化可以應用於整個函式，或者可以使用外框化來啟用函式部分的最佳化。從 JIT’d 程式碼重新進入 JIT 基礎架構可以在現有的延遲編譯之上實作，或者透過自訂路徑實作。

無論採用何種設計，目標是基礎架構應該是通用的，以便其他 LLVM API 用戶端可以使用它，並且應該支援進程外 JIT 編譯 (因此某些解決方案將在 ORC 執行階段中實作)。

預期結果

• 改善間接參照的人體工學設計 – 理想情況下，所有形式的間接參照 (用於重新最佳化、延遲編譯和程序連結表) 都應該能夠在執行階段共用單一 stub (和/或二進位重寫中繼資料)。
• 在整理後的間接參照之上實作基本重新最佳化。
• (延伸目標) 垃圾回收不再需要的未最佳化程式碼，一旦最佳化版本可用。

理想技能： 中級 C++；理解 LLVM 和 LLVM JIT，尤其重要。

專案規模： 大型。

難度： 中等

已確認指導老師： Vassil Vassilev、Lang Hames

討論區： URL

專案描述： JITLink 是 LLVM 的新 JIT 連結器 API – 低階 API，可將編譯器輸出 (可重定位物件檔案) 轉換為記憶體中可執行的位元組。為此，JITLink 的通用連結器演算法需要專門化，以支援目標物件格式 (COFF、ELF、MachO) 和架構 (arm、arm64、i386、x86-64)。LLVM 已經擁有成熟的 JITLink 實作，適用於 MachO/arm64、MachO/x86-64、ELF/x86-64、ELF/aarch64 和 COFF/x86-64，而 ELF/riscv、ELF/aarch32 和 COFF/i386 的實作仍然相對較新。
您可以處理全新的架構 (如 PowerPC 或 eBPF)，或完成最近新增的 JITLink 實作之一。在這兩種情況下，您都可能會重複使用其中一種目標物件格式的現有通用程式碼。您還將處理重定位解析、填充 PLT 和 GOT，並為您選擇的目標連接 ORC 執行階段。

預期成果： 為尚未支援或不完整的格式/架構 (如 PowerPC、AArch32 或 eBPF) 編寫 JITLink 專門化。

理想技能： 中級 C++；理解 LLVM 和 LLVM JIT，尤其重要；熟悉您選擇的格式/架構，以及基本的連結器概念 (例如區段、符號和重定位)。

專案規模： 大型。

難度：中等

已確認指導老師： Vassil Vassilev、Lang Hames

討論區： URL

專案描述： 雖然編譯器的主要工作是產生快速的程式碼 (良好的執行階段效能)，但最佳化不會花費太多時間 (良好的編譯階段效能) 也很重要。此專案的目標是在不損害最佳化品質的情況下，改善編譯時間。
此專案的總體方法是

1. 選擇要最佳化的工作負載。例如，這可以是從 CTMark 取得的檔案，以特定的建置組態 (例如 -O0 -g 或 -O3 -flto=thin) 編譯。
2. 收集效能分析資訊。這可能涉及編譯器選項，例如 -ftime-report 或 -ftime-trace 以獲得高階概觀，以及 perf record 或 valgrind --tool=callgrind 以獲得詳細的效能分析。
3. 識別異常緩慢的位置。這在很大程度上取決於工作負載。
4. 嘗試最佳化已識別的熱點，理想情況下不影響產生的程式碼。編譯時間追蹤器可用於快速評估對 CTMark 的影響。

預期成果： 某些個別檔案的顯著改進 (多個百分點)，以及總體幾何平均編譯時間的小幅改進。

理想技能： 中級 C++。熟悉效能分析工具 (如果您不是在 Linux 上，情況尤其如此，在這種情況下我將無法提供協助)。

專案規模： 中等或大型。

難度： 中等

已確認指導老師： Nikita Popov

討論區： URL

專案描述： Rust 程式語言使用 LLVM 進行程式碼生成，並嚴重依賴 LLVM 的最佳化功能。然而，在許多情況下，LLVM 無法最佳化 rustc 發出的典型程式碼模式。此類問題會使用 I-slow 和/或 A-LLVM 標籤回報。
修復這些問題的常用方法是

1. 在 Godbolt 上檢查 --emit=llvm-ir 輸出。
2. 建立一個 LLVM IR 測試案例，該案例在透過 opt -O3 執行時未最佳化。
3. 識別最小的遺失轉換，並使用 alive2 證明其正確性。
4. 識別哪個或哪些 LLVM pass 可以執行轉換。
5. 新增必要的測試覆蓋率並實作轉換。
6. (稍後：檢查在 Rust 中下一個主要 LLVM 版本升級後，問題是否真正解決。)

預期成果： 修復許多容易到中等的 Rust 最佳化失敗問題。即使未實作任何修復，也針對某些失敗進行初步分析。

理想技能： 用於實作的中級 C++。對 LLVM 的一些熟悉度 (至少能夠理解 LLVM IR) 用於分析。基本的 Rust 知識 (足以閱讀，但不能編寫 Rust)。

專案規模： 中等或大型。

難度： 中等

已確認指導老師： Nikita Popov

討論區： URL

專案描述： Clang 編譯器是 LLVM 編譯器基礎架構的一部分，支援多種語言，例如 C、C++、ObjC 和 ObjC++。 LLVM 和 Clang 的設計使其能夠作為函式庫使用，並促成了整個編譯器輔助工具生態系統的創建。 Clang 相對友善的程式碼庫以及 LLVM 中 JIT 基礎架構的進步，進一步推動了對不同 C++ 處理方法的研究，模糊了編譯時間和運行時間之間的界線。 挑戰包括增量編譯以及將編譯/連結時間最佳化融入更動態的環境中。

增量編譯管線透過建置不斷成長的翻譯單元，逐區塊處理程式碼。然後將程式碼降低到 LLVM IR 中，並隨後由 LLVM JIT 執行。此類管線允許建立有效率的直譯器。直譯器啟用互動式探索，並使 C++ 語言更易於使用。增量編譯模式由互動式 C++ 直譯器 Cling 使用，Cling 最初是為了在 C++ 環境中啟用互動式高能物理分析而開發的。

我們的團隊致力於透過一個名為 clang-repl 的新工具，將 Cling 的部分內容納入並可能重新設計到 Clang 主線中。該專案旨在設計和實作穩健的自動完成功能，當使用者在 clang-repl 的提示字元下輸入 C++ 時。例如

      [clang-repl] class MyLongClassName {};
      [clang-repl] My<tab>
      // list of suggestions.
    

預期成果： 有幾個預期的任務

• 研究 clang 中自動完成的目前方法，例如 clang -code-completion-at=file:col1:col2。
• 使用 clang 的 libInterpreter 中的部分翻譯單元基礎架構，實作自動完成支援的版本。
• 研究語意自動完成的要求，這會將程式碼的精確語法位置和語意納入考量。例如

            [clang-repl] struct S {S* operator+(S&) { return nullptr;}};
            [clang-repl] S a, b;
            [clang-repl] v = a + <tab> // shows b as the only acceptable choice here.
          

• 在相關的會議和研討會上展示這項工作。

專案規模：大型。

難度： 中等

已確認指導教授： Vassil Vassilev

討論區： URL

專案描述： Clang 目前在每個 clang 執行個體中獨立處理模組，使用檔案系統來同步哪個執行個體建置給定的模組。由於為模組重用和檔案系統爭用而做出的權衡，這在健全性和效能方面存在許多問題。

Clang 還有另一種建置模組的方式，即顯式建置模組，目前需要變更建置系統才能採用。在這裡，建置系統決定需要哪些模組，例如透過使用 clang-scan-deps，並確保在執行需要它們的 clang 編譯任務之前，先建置這些模組。

為了允許採用這種新的模組建置方式，而無需進行重大的建置系統工作，我們需要一個模組建置守護程式。透過對命令列進行小幅變更，clang 將連線到此守護程式，並要求它需要的模組。然後，模組建置守護程式會傳回現有的有效模組，或建置然後傳回它。

在 llvm-project 分支中，有一個現有的開放原始碼相依性掃描守護程式。這僅處理檔案相依性，但具有 IPC 機制。此 IPC 系統可以用作模組建置守護程式的基礎，但確實需要擴展到可在 Windows 上運作。

預期成果： 使用 Clang 模組和現有建置系統 (如 Make 或 CMake) 的正常專案，可以僅透過模組建置守護程式，使用顯式建置模組來建置。

理想技能： 中級 C++ 程式設計技能；熟悉編譯器；熟悉 Clang 是一種優勢，但非必要條件。

專案規模： 175 小時或 350 小時，取決於 IPC 的重用情況

難度： 中等

已確認指導老師： Michael Spencer、Jan Svoboda

討論區： URL

專案描述： Swift-DocC 是 Swift OSS 專案的標準文件編譯器。然而，Swift-DocC 並非 Swift 專用，而是使用 SymbolKit 的語言不可知、基於 JSON 的符號圖格式，來理解程式碼中可用的符號，這樣，只要有符號圖產生器，Swift-DocC 就可以支援任何語言。

Clang 支援 C 和 Objective-C 的符號圖生成，如 [RFC] clang support for API information generation in JSON 中所述。如今，對 Objective-C 類別的支援尚不完整，一方面，如果類別擴展了目前模組中的類型，則類別成員會被假定屬於擴展類型本身。另一方面，如果擴展類型屬於另一個模組，則會忽略該類別。儘管如此，在 Objective-C 中擴展屬於其他模組的類型，作為模組公用 API 的一部分是很常見的。此專案的目標是擴展符號圖格式以容納 Objective-C 類別，並實作支援，以透過 clang 和 libclang 產生此資訊。

預期成果： 在 clang 的符號圖產生器和 libclang 中新增必要的支援，以描述在其他模組中定義的符號類別。這可能涉及對 SymbolKit 的新增內容，需要與該社群討論。

理想技能： 中級 C++ 程式設計技能；熟悉 clang 和 Objective-C 是一種優勢，但非必要條件。

專案規模： 中等

難度： 中等

已確認指導老師： Daniel Grumberg、Zixu Wang、Juergen Ributzka

討論區： URL

專案描述： Swift-DocC 是 Swift OSS 專案的標準文件編譯器。然而，Swift-DocC 並非 Swift 專用，而是使用 SymbolKit 的語言不可知、基於 JSON 的符號圖格式，來理解程式碼中可用的符號，這樣，只要有符號圖產生器，Swift-DocC 就可以支援任何語言。

Clang 支援 C 和 Objective-C 的符號圖生成，如 [RFC] clang support for API information generation in JSON 中所述。

目前，發射的符號圖格式不支援各種 C++ 建構，例如範本和例外狀況，且符號圖產生器不完全理解 C++。此專案旨在在符號圖格式中引入對各種 C++ 建構的支援，並實作支援，以在 clang 中產生此資料。

預期成果： 在 clang 的符號圖產生器和 libclang 中新增必要的支援，以描述在其他模組中定義的符號類別。這將涉及對 SymbolKit 的新增內容，需要與該社群討論。

理想技能： 中級 C++ 程式設計技能；熟悉 clang 和 Objective-C 是一種優勢，但非必要條件。

專案規模： 大型

難度： 中等/困難

已確認指導老師： Daniel Grumberg、Zixu Wang、Juergen Ributzka

討論區： URL

專案描述： Swift-DocC 是 Swift OSS 專案的標準文件編譯器。然而，Swift-DocC 並非 Swift 專用，而是使用 SymbolKit 的語言不可知、基於 JSON 的符號圖格式，來理解程式碼中可用的符號，這樣，只要有符號圖產生器，Swift-DocC 就可以支援任何語言。

Clang 支援 C 和 Objective-C 的符號圖生成，如 [RFC] clang support for API information generation in JSON 中所述。

目前，使用者可以使用 clang，透過 clang -extract-api 命令列介面產生符號圖檔案，或使用 libclang 介面為特定符號產生符號圖。此專案將需要新增第三種模式，該模式將在常規編譯工作的副作用中產生符號圖輸出。這可以啟用將符號圖格式用作 clang Index 或 clangd 的輕量級替代方案，以用於程式碼智慧服務。

預期成果： 啟用在常規編譯 (或模組建置) 期間產生符號圖檔案；提供一種工具來合併符號圖檔案，其方式與靜態連結器連結個別物件檔案的方式相同；擴展 clang Index 以支援符號圖檔案包含的所有資訊。

理想技能： 中級 C++ 程式設計技能；熟悉 clang 和 Objective-C 是一種優勢，但非必要條件。

專案規模： 中等

難度： 中等/困難

已確認指導老師： Daniel Grumberg、Zixu Wang、Juergen Ributzka

討論區： URL

專案描述： clang 發射的診斷訊息最終是其開發人員的介面。雖然診斷訊息通常良好，但仍有一些粗糙的地方需要磨平。有些情況也可以透過在編譯器中特殊處理來改善。

正如人們可以從 Clang 的問題追蹤器中看到的那樣，針對 clang 的診斷訊息，有 許多問題 處於開啟狀態。

此專案的目標不是實作一個大型功能，而是專注於對 Clang 診斷訊息進行較小的增量改進。

可能要解決的範例問題

• 在 constexpr 函式中呼叫 nullptr 函式指標會導致不良的診斷訊息
• 列印未初始化子物件的名稱 (而不是類型)
• https://github.com/llvm/llvm-project/issues/57906
• clang(++) 無幫助的 frame-larger-than 警告，非常小的堆疊框架超出非常大的限制
• 您發現有趣或個人遇到的任何其他診斷訊息問題。

預期成果：至少三個已修復的較小診斷訊息問題，或一個已實作的較大診斷訊息改進。

已確認指導老師：Timm Bäder

期望的技能

• 中級 C++ 知識。
• 最好具備 Clang 程式碼庫的經驗，因為所提及的問題可能在 Clang 程式碼庫的各個部分中都有其根本原因。
• 最好是已運作的本機 LLVM 建置版本

專案類型： 中等/200 小時

討論區 URL

專案描述： Clang 編譯器是 LLVM 編譯器基礎架構的一部分，支援各種語言，例如 C、C++、ObjC 和 ObjC++。LLVM 和 Clang 的設計使其可以用作函式庫，並促成了整個編譯器輔助工具生態系統的建立。Clang 相對友好的程式碼庫和 LLVM 中 JIT 基礎架構的進展，進一步促成了對處理 C++ 的不同方法的研究，模糊了編譯時間和執行階段之間的界線。挑戰包括增量編譯和將編譯/連結時間最佳化納入更動態的環境中。

增量編譯管線透過建置不斷成長的翻譯單元，逐區塊處理程式碼。然後將程式碼降低到 LLVM IR 中，並隨後由 LLVM JIT 執行。此類管線允許建立有效率的直譯器。直譯器啟用互動式探索，並使 C++ 語言更易於使用。增量編譯模式由互動式 C++ 直譯器 Cling 使用，Cling 最初是為了在 C++ 環境中啟用互動式高能物理分析而開發的。

我們投入精力，透過一個名為 clang-repl 的新工具，將 Cling 的部分內容納入並可能重新設計到 Clang 主線中。該專案旨在實作教學課程，示範專案的功能，並研究在 xeus-clang-repl 原型中採用 clang-repl，以允許在 Jupyter 中編寫 C++。

預期成果： 有幾個預期的任務

• 編寫幾個教學課程，示範 clang-repl 的目前功能。
• 研究將 clang-repl 新增為 xeus-cling 後端的必要條件。
• 改善 clang-repl 的 xeus 核心協定。
• 準備一篇關於 clang-repl 以及可能的 Jupyter 的部落格文章。在相關的會議和研討會上展示這項工作。

已確認指導老師： Vassil Vassilev David Lange

理想技能： 中級 C++；理解 Clang 和 Clang API，尤其重要

專案類型： 中等

討論區 URL

專案描述： Clang 編譯器是 LLVM 編譯器基礎架構的一部分，支援各種語言，例如 C、C++、ObjC 和 ObjC++。LLVM 和 Clang 的設計使其可以用作函式庫，並促成了整個編譯器輔助工具生態系統的建立。Clang 相對友好的程式碼庫和 LLVM 中 JIT 基礎架構的進展，進一步促成了對處理 C++ 的不同方法的研究，模糊了編譯時間和執行階段之間的界線。挑戰包括增量編譯和將編譯/連結時間最佳化納入更動態的環境中。

增量編譯管線透過建置不斷成長的翻譯單元，逐區塊處理程式碼。然後將程式碼降低到 LLVM IR 中，並隨後由 LLVM JIT 執行。此類管線允許建立有效率的直譯器。直譯器啟用互動式探索，並使 C++ 語言更易於使用。增量編譯模式透過 xeus 核心協定，用於 Jupyter 中的互動式 C++。較新版本的協定允許可能的瀏覽器內執行，為 clang-repl 和 Jupyter 提供更多可能性。

我們投入精力，透過一個名為 clang-repl 的新工具，將 Cling 的部分內容納入並可能重新設計到 Clang 主線中。該專案旨在在 clang-repl 中新增 WebAssembly 支援，並在 xeus-clang-repl 中採用它，以協助基於 Jupyter 的 C++。

預期成果： 有幾個預期的任務

• 研究以類似於新的 互動式 CUDA 支援的方式產生 WebAssembly 的可行性。
• 啟用在 clang-repl 中產生 WebAssembly。
• 在 xeus-clang-repl 中採用該功能。
• 準備一篇關於 clang-repl 以及可能的 Jupyter 的部落格文章。在相關的會議和研討會上展示這項工作。

已確認指導老師： Vassil Vassilev Alexander Penev

理想技能： 良好 C++；理解 Clang 和 Clang API 以及 LLVM JIT，尤其重要

專案類型： 大型

討論區 URL

專案描述 GNU 工具鏈廣泛用於建置嵌入式目標。Clang/LLVM 社群在改進 Clang 工具鏈以支援嵌入式目標方面具有一定的動力。使用 Clang 工具鏈作為替代方案，可以幫助我們提高程式碼品質、尋找和修復安全性錯誤、改善開發人員體驗，並利用圍繞 Clang/LLVM 社群在支援嵌入式裝置方面的新想法和動力。

可以對 LLD 進行的非詳盡改進清單:

• --print-memory-usage 支援

  GCC 中的「--print-memory-usage」提供連結器檔案中定義的每個記憶體區域中使用的記憶體細目。嵌入式開發人員使用此旗標來了解對記憶體的影響。嵌入式系統通常定義具有不同空間限制的多個記憶體區域。在 Clang 工具鏈中支援此功能，將有助於希望在其專案中使用 Clang 工具鏈的專案。

• 連結地圖

  目前，LLD 連結器的連結地圖輸出不如 BFD 連結器輸出豐富。在連結地圖輸出上實現功能對等，對於分析 LLD 連結器建立的二進位檔案非常有用。此外，以不同格式 (目前的 LLD 輸出、BFD 和 JSON) 輸出連結地圖，可以幫助建置自動化工具來調查連結器產生的成品。

• --print-gc-sections 改進

  當啟用「--print-gc-sections」旗標時，LLD 會列印在連結過程中捨棄的區段。此資訊目前不包含符號與區段群組之間的對應，這對於偵錯很有用。在連結過程中保留此資訊，將需要修改內部連結器資料結構。

專案規模： 中等或大型

難度： 中等/困難

技能： C++

預期結果:

• 實作「--print-memory-usage」旗標。
• 支援新的連結地圖輸出格式 1. BFD 和 2. JSON。
• 改進「--print-gc-sections」輸出，以包含有關倖存符號的資訊。

已確認指導老師： Prabhu Rajasekaran Petr Hosek

討論區： URL

專案描述： MLIR 的 Presburger 函式庫 FPL (https://grosser.science/FPL) 為多面體編譯和分析提供數學抽象。該函式庫提供的主要抽象是由仿射不等式約束系統定義的整數元組集合。該函式庫支援對此類集合的標準集合運算。結果將是由另一個約束系統定義的集合，可能具有更多約束。當循序執行許多集合運算時，約束系統可能會變得非常大，從而對效能產生負面影響。有幾種潛在的方法可以簡化約束系統；然而，這涉及執行額外的計算。因此，花費更多時間進行更積極的簡化可能會使每個個別運算變慢，但同時，不充分的簡化可能會由於約束系統大小的爆炸性增長而使運算序列變慢。此專案的目標是找到兩者之間的適當平衡點。

此專案的目標

• 了解函式庫在執行階段和輸出大小方面的效能。
• 透過找出最佳輸出大小和效能之間的權衡，來最佳化程式庫。

預期成果:

• 為程式庫的主要操作進行效能基準測試和輸出限制複雜度分析。
• 實作簡化啟發式演算法。
• 更深入了解哪些簡化啟發式演算法能充分提升整體效能，使其值得額外的運算成本。

理想技能: 中階 C++、基準測試經驗

專案規模: 大型

難度: 中等

已確認導師: Kunwar Grover

討論區: 網址

專案描述: 此專案旨在為 MLIR 開發一個互動式查詢語言，讓開發人員能夠動態查詢 MLIR IR。此工具將提供 REPL（或命令列）介面，讓使用者能夠查詢 MLIR 程式碼的各種屬性，例如「isConstant」和「resultOf」。此提案工具旨在與 clang-query 類似，後者允許開發人員使用具有自動完成和其他功能的 TUI，在 C++ 程式碼中比對 AST 表達式。

此專案的目標

• 理解 MLIR IR 表示法以及使用者進行的常見探索。
• 實作 REPL 以執行 MLIR IR 上的查詢。

預期成果:

• 可獨立使用，以互動方式探索 IR。
• 實作此工具可使用的常見比對器。
• (延伸目標) 啟用將查詢比對到的 IR 部分提取到獨立的 IR 片段中。

理想技能: 中階 C++、編寫/偵錯 peephole 最佳化經驗

專案規模: 中型或大型。

難度: 中等

已確認導師: Jacques Pienaar

討論區: 網址

專案描述 我們正在實際部署中使用機器引導的編譯器最佳化（「MLGO」），以進行暫存器配置逐出和大小內聯。機器學習模型已使用強化學習演算法進行訓練。擴展到更多效能領域目前受到效能估計模型預測品質不佳的阻礙。改善這些模型對於強化學習訓練演算法的有效性至關重要，因此對於系統性地將 MLGO 應用於更多最佳化至關重要。

專案規模： 175 或 350 小時。

難度： 中等

技能： C/C++、一些編譯器經驗、一些 Python。機器學習經驗是加分項。

預期成果：透過包含額外的執行階段/效能分析資訊（例如額外的 PMU 資料、LLC 未命中機率或分支預測錯誤）來更好地建立執行環境模型。這包括 (1) 建立涵蓋額外執行階段資訊的資料收集管線，(2) 修改機器學習模型以允許處理此資料，以及 (3) 修改模型的訓練和推論過程以使用此資料。

如今，這些模型幾乎是純粹的靜態分析；它們會查看指令，但對於程式碼的執行環境和執行階段行為做出一體適用的假設。此專案的目標是從靜態分析轉向更能代表程式碼實際執行方式的動態模型。

導師 Ondrej Sykora、Mircea Trofin、Aiden Grossman

討論區 網址

專案描述： Clang 靜態分析器帶有一個實驗性的汙染分析實作，這是一種以安全性為導向的分析技術，旨在警告使用者受攻擊者控制（「汙染」）的資料流入敏感函數，如果攻擊者能夠偽造正確的輸入，這些函數可能會以意外且危險的方式運作。程式設計師可以透過正確地「清理」受汙染的資料來解決此類警告，以消除這些危險的輸入。以這種方式可以捕獲的常見問題範例是 SQL 注入。一個更簡單的範例，可以說與 Clang 使用者更相關，是由攻擊者控制的數字引起的緩衝區溢位漏洞，這些數字在疊代堆疊或堆積陣列時用作迴圈邊界，或作為引數傳遞給低階緩衝區操作函數，例如memcpy().

作為一個靜態符號執行引擎，靜態分析器透過簡單地維護在符號模擬期間從已知汙染源獲得的「符號」（命名的未知數值）列表來實作汙染分析。然後，這些符號被視為可能採用任意具體值，而不是採用可能值的未知子集的一般情況。例如，除以未檢查的未知值不一定保證除以零警告，因為通常不知道該值是否可能為零。但是，除以未檢查的受汙染值會立即保證除以零警告，因為攻擊者可以自由地傳遞零作為輸入。因此，靜態分析器的汙染基礎結構由幾個部分組成：有一種機制用於追蹤符號程式狀態中的受汙染符號，有一種方法可以定義新的汙染源，並且教導了一些路徑敏感檢查來使用汙染資訊以發出額外的警告（例如除以零檢查器），充當汙染「接收器」並定義檢查器特定的「清理」條件。

整個設施都被標記為實驗性的：它基本上是一個概念驗證實作。它很可能可以做得非常好，但它需要透過在真實世界的原始碼上運行來進行一些品質控制，並且需要解決許多錯誤，尤其是在個別檢查中，然後我們才能宣告它穩定。此外，所有檢查中最吸引人的檢查 – 基於受汙染的迴圈邊界或大小參數的緩衝區溢位偵測 – 從未實作過。還有一個相關的檢查用於使用受汙染的索引進行陣列存取 – 這再次是實驗性的；讓我們看看我們是否也可以宣告這個檢查穩定！

預期結果： 許多與汙染相關的檢查，預設為靜態分析器的所有使用者啟用，或作為選擇加入提供給關心安全性的使用者。它們被確認在真實世界的程式碼上具有低誤報率。希望緩衝區溢位檢查是其中之一。

理想技能： 中階 C++，能夠理解 LLVM 程式碼。我們也將在一些純 C 程式碼上運行我們的分析。編譯器或安全性方面的一些背景知識是受歡迎的，但並非絕對必要。

專案規模： 中等或大型。

難度： 中等

已確認導師： Artem Dergachev、Gábor Horváth、Ziqing Luo

討論區： 網址

專案描述 這延續了 GSoC 2020 和 2021 的工作。開發人員通常使用標準最佳化管線（如 -O2 和 -O3）來最佳化他們的程式碼。手動製作的啟發式演算法用於確定要選擇哪些最佳化傳遞以及如何排序這些傳遞的執行。但是，此過程並非針對特定程式或程式類型量身定制，因為它旨在對任何輸入執行「相當好」。我們希望改進現有的啟發式演算法或用基於機器學習的模型取代啟發式演算法，以便 LLVM 編譯器可以為每個程式提供卓越的傳遞順序。最後一個里程碑啟用了特徵提取，並開始研究訓練策略以選擇更合適的傳遞管線。

專案規模： 175 或 350 小時。

難度： 中等

技能： C/C++、一些編譯器經驗。機器學習經驗是加分項。

預期成果：預先訓練的模型，選擇最經濟的最佳化管線，且效能沒有損失；在 LLVM 中掛鉤模型；（重新）訓練工具；透過搜尋或學習提出新的最佳化序列。

導師 Tarindu Jayatilaka、Mircea Trofin、Johannes Doerfert

討論區 網址

專案描述
Clang 支援基於原始碼的覆蓋率，顯示已執行的測試涵蓋了哪些程式碼行 [1]。它使用 llvm-profdata [2] 和 llvm-cov [3] 工具來產生覆蓋率報告。 llvm-cov 目前產生單個頂層索引 HTML 檔案。例如，LLVM 儲存庫的單個頂層目錄程式碼覆蓋率報告 [4] 發佈在覆蓋率機器人上。頂層索引會導致大型專案（如 Fuchsia [5]）中的渲染可擴展性問題。此專案的目標是在產生的覆蓋率 html 報告中產生階層式目錄結構，以符合目錄結構並解決可擴展性問題。 Chromium 使用其自己的後處理工具來顯示每個目錄的覆蓋率結果階層式結構 [6]。同樣，Lcov（Gcov 的圖形前端 [7]）提供單層目錄結構來顯示覆蓋率結果 [8]。
[1] 基於原始碼的程式碼覆蓋率
[2] llvm-profdata
[3] llvm-cov
[4] LLVM 覆蓋率報告
[5] Fuchsia
[6] Chromium 的覆蓋率摘要
[7] Gcov
[8] Lcov 覆蓋率報告
[9] Issue #54711：支援 HTML 覆蓋率報告的每個目錄索引檔案

預期成果： 在產生的覆蓋率 html 報告中實作階層式目錄結構的支援，並在 LLVM 儲存庫程式碼覆蓋率報告中顯示此功能的使用方式。

專案規模： 中等或大型

難度： 中等

已確認導師： Gulfem Savrun Yeniceri Petr Hosek

討論區： 網址

專案描述 開發人員經常使用編譯器產生的備註和分析報告來最佳化他們的程式碼。雖然編譯器通常擅長在產生的訊息中包含原始碼位置（即行號和欄號），但如果這些產生的訊息也包含對應的原始碼層級表達式，則會很有用。 LLVM 實作使用的方法是使用一小組內部函數來定義 LLVM 程式物件與原始碼層級表達式之間的對應。此專案的目標是使用包含在這些內部函數中的資訊來產生對應於 LLVM 值的原始碼表達式，或提出和實作解決方案，以便在現有資訊不足的情況下獲得相同的結果。最佳化程式中的記憶體存取對於應用程式效能非常重要。我們特別打算使用編譯器分析訊息，這些訊息報告對應於 LLVM 載入/儲存指令的原始碼層級記憶體存取，這些指令會抑制編譯器最佳化。例如，我們可以使用此資訊來報告抑制向量化的記憶體存取依賴性。

專案規模： 中等

難度： 中等

技能： 中階 C++、熟悉 LLVM 核心或願意學習。

預期成果： 提供一個介面，該介面接受 LLVM 值並傳回對應於等效原始碼層級表達式的字串。我們特別感興趣的是使用此介面將載入/儲存指令中使用的位址對應到等效的原始碼層級記憶體參考。

已確認導師： Satish Guggilla (satish.guggilla@intel.com) Karthik Senthil (karthik.senthil@intel.com)

討論區： 網址

    std::vector<std::string> vs;
    int n = vs.front(); // bad diagnostic: [...] aka 'std::basic_string<char>' [...]

    template<typename T> struct Id { typedef T type; };
    Id<size_t>::type // just 'unsigned long', 'size_t' sugar has been lost
    

    auto [x, y] = ...;

    #include <memory>

    int foo(bool flag) {
      std::unique_ptr<int> x;  // note: Default constructor produces a null unique pointer;

      if (flag)                // note: Assuming 'flag' is false;
        return 0;              // note: Taking false branch

      return *x;               // warning: Dereferenced smart pointer 'x' is null.
    }