欢迎有志参加 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: URL

描述

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: URL

描述

现代 GPU 能够与主机进行统一寻址。我们目前使用它通过 RPC 接口 提供 I/O 支持。但是，这需要在 CPU 上使用专用用户线程来处理服务器代码。我们希望探索使用 Linux io_uring 接口从 GPU 提供 I/O 的替代方案。

此接口是一个旨在加速 syscall 的环形缓冲区。但是，它提供了一种 轮询模式，允许内核刷新环形缓冲区，而无需用户启动系统调用。我们应该能够使用 AMD 和 NVIDIA API 调用将 mmap() 内存注册到 GPU。此接口应该允许我们实现一个基本的读/写接口，该接口可以被认为与 CPU 上的 syscall 相同。然后可以使用它来实现完整的文件接口。

预期结果

• 在 GPU 上运行的 pwrite 和 pread 的实现。
• 通过将 snprintf 转发到 pwrite 来支持 printf。
• 如果时间允许，探索 GPU 文件 API。

技能

基本 C & C++ 技能 + 访问 GPU、Linux 内核知识、GPU 知识。

项目规模： 小型

难度： 困难

已确认的导师： Joseph Huber, Tian Shilei

Discourse: URL

描述

LLVM C 库提供了数学函数的实现。我们希望将这些函数与现有实现进行性能分析比较，例如 CUDA 的 libdevice、ROCm 的 device libs 和 OpenCL 的 libclc。去年，我们致力于一些接口来支持这些测试，现在需要对这些接口进行改进和完善，以用于有趣的函数。

此外，我们希望通过暴力测试来验证这些函数在 GPU 上运行时是否准确。目标是验证这些实现是正确的，并且至少符合 OpenCL 标准 中的误差范围。这将需要一组在 offload/ 项目中编写的单元测试，最好使用 @callumfare 正在开发的新 API。

预期结果

• 最终性能结果类似于 旧结果，但具有更优化的函数和更高的精度。
• 一个可以进行暴力测试以确认实现是否符合标准的测试套件。

技能

基本 C & C++ 技能 + 访问 GPU，一些数学知识

项目规模： 小型

难度： 简单/中等

已确认的导师： Joseph Huber, Tue Ly

Discourse: URL

描述： 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: URL

描述： ClangIR 是一种新的、基于 MLIR 的 C 和 C++ 代码中间表示。它是在 LLVM 孵化器项目中开发的，但现在正在进行将代码从孵化器迁移到主 LLVM 存储库的工作。在代码迁移过程中，必须对其进行更新，以符合 LLVM 编码标准和质量期望。该项目的目标是参与 ClangIR 上游化过程，并帮助改进代码和上游化过程。

ClangIR 项目旨在通过添加更紧密地模拟源结构的新抽象来解锁 C 和 C++ 代码的更好优化、分析和诊断的可能性，从而保留比标准 LLVM IR 中更多的细节。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: URL

描述： 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: URL

描述

目前，没有简单的方法来获取使用 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: URL

描述

未定义行为消毒器 (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-fsanitize-trap=标志也传递。应该教导 Clang 警告这一点。标志单独传递时，编译器会静默忽略它。目前，Clang 要求
• 教导 Clang 在 UBSan 陷阱指令上的调试信息中发出 UBSan 陷阱原因，类似于__builtin_verbose_trap的工作方式。
• 确认 LLDB 能够识别 UBSan 陷阱原因并为此添加测试。
• 如果时间允许，我们应该研究通过使用编译器中可用的信息来发出更精确的陷阱原因。我们可能希望实现类似于“Sema Diagnostic”的方法，其中可以在编译器内部轻松构建陷阱原因字符串。此任务更开放，并且可能在 UBSan 之外有用途（例如-fbounds-safety).

已确认的导师及其联系方式

• Dan Liew
• Michael Buch

所需技能

良好理解 C++

理想技能

• 熟悉 UBSan
• 熟悉 LLDB

项目规模

小型（~90 小时）。但如果时间允许，可以延长

项目难度

简单。这个项目对于 LLVM 的初学者来说是不错的。请注意，“发出更精确的陷阱原因”部分更开放，因此其难度完全取决于申请人选择的方向。

Discourse: URL

项目描述： Clang-Doc 是一个 C/C++ 文档生成工具，作为 Doxygen 的替代品而创建，并构建于 LibTooling 之上。这项工作始于 2018 年，并在 2019 年取得了重大进展，但其开发在很大程度上处于停滞状态，主要是由于资源匮乏，直到去年作为一个成功的 Google Summer of Code 项目重新启动开发。

该工具构建于 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 论坛： URL

项目描述： 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

Discourse 论坛： URL

描述

Enzyme 需要关于类型内存布局的良好信息。LLVM-IR 是有意不透明的，例如 `&f32` 和 `&f64` 都具有 LLVM-IR 类型 `ptr`。Enzyme 通常能够通过使用分析来推断底层类型（例如 f32 与 f64），但该过程很慢，并且在某些情况下可能会失败。为了使 autodiff 更加健壮，我们应该将 MIR 或 THIR 类型信息降级到 LLVM-IR 元数据中。此分析是递归的，例如 `&[T]` 是一个胖指针，因此将在 LLVM-IR 中表示为 (ptr, int) 对。在这种情况下，算法还应递归分析 `T` 并为其生成元数据。

可以扩展 这里的 函数以从 rusts Mid-level IR (MIR) 生成元数据。解析器的原型已在 这里 实现，可用于提供灵感。可以在 此 测试文件夹中找到我们想要生成的元数据的各种 LLVM-IR 示例。查找 ` {[-1]:Pointer, [-1,0]:Float@float}` 风格的注释。

在线编译器 Explorer 分支可用于触发相关错误，从“无法推断 X 的类型”开始。

预期成果

参与者应查找并选择一些有趣的测试用例，在这些用例中，Enzyme 要么由于类型信息不足而无法区分示例，要么花费了不合理的长的时间（例如，比不使用 autodiff 编译代码慢 20 倍以上）。在第二种情况下，应使用性能分析器来验证 Enzyme 是否由于类型分析而导致编译时间过长。然后，参与者应编写（或稍后扩展）类型解析器以生成正确的元数据，以便 Enzyme 可以处理新的测试用例。LIT 测试用例应添加到 rust 编译器中，以避免进一步的回归。

目前未正确处理的代码示例可以在项目提案阶段进行讨论。

已确认的导师及其联系方式

• Manuel Drehwald
• Oli Scherer
• Johannes Doerfert

所需技能

Rust 和 C++ 中级知识；熟悉性能分析器或 LLVM 元数据是加分项，但不是必需的。

项目规模

中等 (~175 小时)

项目难度

中等

Discourse 论坛： URL

描述： 目前，每个想要支持调用 C 代码 (FFI) 的基于 LLVM 的前端都需要重新实现大量的复杂调用 ABI 处理。本项目的目标是引入一个 LLVM ABI 库，该库可以在不同的前端（包括 Clang）之间重用。有关动机和设计概要的更多详细信息，请参见 相应的 RFC。

该项目的初始阶段将是实现一个原型，该原型至少可以处理 x86_64 System V ABI。这将涉及实现 ABI 类型系统，将 Clang 类型映射到 ABI 类型，以及将 Clang 的 X86 ABIInfo 实现的至少一部分移动到新的 ABI 库。这是为了证明总体可行性，找出设计问题并分析编译时间的影响。

假设原型的结果是积极的，下一步将是通过将其拆分为较小的 PR 来向上游提交实现。最后，可以扩展实现以涵盖其他目标，最终完全删除 Clang 的 ABI 处理代码。

预期结果： 最低结果是 x86_64 ABI 的原型。最大结果是完全向上游提交对所有目标的支持。预期结果介于两者之间。

技能： C++ 中级。 对 LLVM 有一定的熟悉度是加分项，但不是必需的。

项目规模： 大型

难度： 困难

已确认导师： Nikita Popov

Discourse 论坛： URL

描述： 由于缺乏表示原始内存的方式，LLVM IR 无法正确表示 memcpy、memcmp 等的实现。本项目旨在向 LLVM IR 添加一个新的“byte”类型来表示原始内存。

除了添加新类型之外，该项目还涉及更改 clang 以将 chars 降级为新的 b8 类型而不是 i8，修复内存内部函数的错误降级，并跟踪性能回归。

已经有一个针对旧版本 LLVM 的 byte 类型的 原型 实现。更多信息请参见 这里。

预期结果： 最低结果是将现有原型移植到当前 LLVM，修复所有已知的错误优化，为 Alive2 添加 byte 类型支持，以及性能分析。

技能： C++ 中级，熟悉 LLVM，性能分析。

项目规模： 大型

难度： 困难

已确认导师： Nuno Lopes

Discourse 论坛： URL

描述： LLVM 通过 remarks、性能分析或运行时调试注释（例如，LIBOMPTARGET_INFO=-1）提供不同的信息。但是，随着项目规模的扩大，用户越来越难以剖析这些信息。例如，在构建大型项目时，很难收集所有这些数据、对其进行可视化并从中学习。

目前，某些此类信息（例如，编译 remarks）可以导出为 JSON 格式。我们希望创建一个工具来可视化、聚合和总结这些信息。为了帮助加速器开发，我们将从 offload 项目开始作为主要候选项目。

类似的工具，例如 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++。
• 全栈 Web 开发。

项目规模： 大型

难度： 简单

Discourse 链接： [GSoC][Offload]LLVM 编译器 Remarks 可视化工具 Offload 提案

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. 用非 UB 模式替换已知的模式，例如 undef/poison 上的分支、具有无效指针的内存访问等。
2. 使用 Alive2 检测更多模式（通过搜索始终为 UB 的测试）。
3. 报告 Alive2 在删除 UB 时发现的任何 LLVM 错误。

预期结果： 大部分 LLVM 的单元测试将不包含 UB。

技能： 需要具有脚本编写（Python 或 PHP）经验。 鼓励具有正则表达式的经验。

项目规模： 中型或大型。

难度： 中等

已确认导师： Nuno Lopes

Discourse 论坛： URL

项目描述： LLVM 中描述 SPIR-V 指令集的现有文件是手动创建的，并且并非总是完整或最新的。每当需要向 SPIR-V 后端添加新指令时，都必须修改该文件。此外，由于它不是以系统的方式创建的，因此 SPIR-V 规范中指令的描述与 TableGen 文件中指令的声明之间通常存在细微的差异。由于 SPIR-V 后端开发人员在开发新功能时经常使用规范作为参考，因此在规范和 TableGen 记录之间建立一致的映射将简化开发。本项目建议创建一个脚本，该脚本能够根据 KhronosGroup/SPIRV-Headers 存储库中提供的 JSON 语法，生成完整的描述 SPIR-V 指令集的 TableGen 文件，并更新 SPIR-V 后端代码以使用新的定义。将 JSON 语法转换为 TableGen 的具体方法由申请人自行决定，但是，应将其检入 LLVM 存储库，并附带详细记录的说明以复制转换过程，以便未来的维护人员能够在语法更改时重新生成文件。请注意，语法本身应保留在树外，位于其现有的单独存储库中。

预期结果

• TableGen 中 SPIR-V 指令集的定义将替换为自动生成的定义。
• 编写一个脚本和文档，以支持根据 SPIR-V 指令集的 JSON 语法，根据需要重新生成定义。
• 更新 SPIR-V 后端中 SPIR-V 指令集的使用，以使用新的自动生成的定义。

技能： 具有脚本编写经验和 C++ 中级知识。 具有 LLVM/TableGen 的先前经验是加分项，但不是必需的。

项目规模： 中型 (175 小时)

已确认导师： Natalie Chouinard, Nathan Gauër

Discourse 论坛： URL

项目描述： LLVM bitstream 文件格式用于序列化中间编译器工件，例如 LLVM IR 或 Clang 模块。在某些情况下，多个 bitstream 文件存储相同的信息，这种重复会导致存储需求增加。

本项目旨在将 LLVM CAS 库集成到 LLVM bitstream 文件格式中。如果我们从 bitstream 文件中提取频繁重复的部分到单独的 CAS 对象中，我们可以用对规范 CAS 对象的小引用替换所有副本，从而节省存储空间。

本项目的主要动机用例是依赖项扫描器，该扫描器为“隐式发现、显式构建”的 Clang 模块提供支持。在实际应用中，即使在块级别进行粗略的去重也可以将扫描模块缓存的大小减半。

预期结果： 有一种方法可以配置 LLVM bitstream 写入器/读取器以使用 CAS 作为后备存储。

技能： C++ 中级知识，对数据序列化有一定的熟悉度，自我激励。

项目规模： 中型或大型

已确认导师： Jan Svoboda, Steven Wu

Discourse 论坛： URL

项目描述： 三向比较 根据值是小于、等于还是大于，返回 -1、0 或 1。它们在 C++ 中通过太空船运算符 (operator<=>) 暴露，在 Rust 中通过 PartialOrd 和 Ord traits 暴露。目前，在某些情况下，此类比较会产生次优的代码生成和优化结果。

本项目的目标是通过实现新的三向比较内部函数来解决这些优化问题，如 [RFC] 添加三向比较内部函数 中所述。实现步骤大致如下

1. 将内部函数添加到 LLVM IR。
2. 在 SelectionDAG 和 GlobalISel 中实现合法化/扩展支持。
3. 在 ConstantFolding、InstSimplify、InstCombine、CorrelatedValuePropagation、IndVarSimplify、ConstraintElimination、IPSCCP 和其他相关转换中实现优化支持。
4. 通过 InstCombine 规范化或在 clang/rustc 中直接发射来使用内部函数。

预期结果： 后端和最重要的优化传递中对内部函数的支持。理想情况下，从前端开始完全集成。

技能： C++ 中级知识

项目规模： 中型或大型

难度： 中等

已确认导师： Nikita Popov, Dhruv Chawla

Discourse 论坛： URL

项目描述： llvm.org 网站是关于 LLVM 项目信息的中心枢纽，涵盖项目详细信息、当前事件和相关资源。随着时间的推移，该网站已自然发展，促使需要重新设计以增强其现代性、结构和易于维护性。

本项目的目标是创建一个现代且连贯的静态网站，以反映 LLVM.org 的精髓。此重新设计旨在改进导航、分类、内容可发现性、移动设备支持、可访问性和整体可用性。鉴于该网站在社区中的关键作用，将努力与社区成员互动，就拟议的更改寻求共识。

预期结果： 一个现代、外观连贯的网站，可以吸引新的潜在用户，并通过更好的导航、分类、内容可发现性和整体可用性来增强现有社区的能力。由于该网站是关键的基础设施，并且大多数社区成员都会对此项目发表意见，因此该项目应尝试与社区互动，就正在采取的步骤建立社区共识。建议的方法

• 对现有网站进行全面的内容审核。
• 选择适当的技术，最好是 Hugo 或 Jekyll 等静态站点生成器。
• 倡导数据和可视化分离，利用 YAML 和 Markdown 等格式来促进内容管理，而无需直接进行 HTML 编码。
• 展示新网站的三个设计模型，促进公开讨论，并为感兴趣的各方提供替代方案留出时间。
• 实施选定的设计，并纳入来自社区的宝贵反馈。
• 与内容创建者协作，根据需要集成或更新内容。

技能： 具有静态站点生成器的 Web 开发领域知识。 html、css、bootstrap 和 markdown 知识。 有耐心和自我激励。

难度： 困难

项目规模： 大型

已确认导师： Tanya Lattner, Vassil Vassilev

Discourse 论坛： URL

项目描述： 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（有关更多详细信息，请参见此 talk）。其次，用户代码中的崩溃意味着整个进程崩溃，从而降低了整体可靠性和易用性。

本项目旨在将 Clang-Repl 迁移到进程外执行模型，以解决这两个问题。

预期结果： 实现 Clang-Repl 的语句的进程外执行； 证明 Clang-Repl 可以支持某些 ez-clang 用例； 研究在崩溃时重启/继续会话的方法； 作为一个延伸目标，设计一种通用的崩溃恢复可靠性方法；

技能： C++ 中级知识，理解 LLVM，特别是 LLVM JIT

项目规模：中型或大型。

难度： 中等

已确认导师： Vassil Vassilev,

Discourse 论坛： URL

项目描述： Clang 编译器是 LLVM 编译器基础设施的一部分，支持多种语言，如 C、C++、ObjC 和 ObjC++。LLVM 和 Clang 的设计允许使用插件 [1] 扩展编译器。插件使得在编译期间运行额外的用户定义操作成为可能。插件在 unix 和 darwin 上受支持，但在 windows 上不受支持，这归因于 windows 平台的一些特殊性。

本项目将使参与者接触到 LLVM 代码库的广泛横截面。它涉及探索 API 表面，将接口分类为公共接口或私有接口，并将该信息注释到 API 声明中。它还将使参与者了解不同平台的详细信息和差异，因为这项工作是跨平台的（Windows、Linux、Darwin、BSD 等）。由此产生的更改将改进 Linux 和 Windows 上的 LLVM，同时在 Windows 上启用新功能。

预期结果： 本项目旨在使 clang -fplugin=windows/plugin.dll 工作。实现方法应扩展工作原型 [3] 并扩展注释工具 [4]。成功的候选人应准备好参加每周会议，进行演示并根据要求准备博客文章。

进一步阅读
[1] https://clang.llvm.net.cn/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

Discourse 论坛： URL

项目描述： Clang，像任何 C++ 编译器一样，线性地解析字符序列。然后，线性字符序列在降级为机器代码之前被转换为标记和 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

Discourse 论坛： URL

项目描述： 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）中汲取其他潜在改进的灵感。

技能： 具有 Web 技术（HTML、CSS、JS）的经验和 C++ 中级知识。 具有 Clang/LibTooling 的先前经验是加分项，但不是必需的。

项目规模： 中型或大型。

难度： 中等

已确认导师： Petr Hosek, Paul Kirth

讨论区： URL

描述

使用调试信息中的变量位置信息来注释 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: URL

描述

LLVM-reduce 和类似的工具执行 delta 调试，但如果存在许多隐式约束，并且违规容易导致类似于要隔离的原因的错误，则它们不太有用。此项目是关于开发一个 GPU 感知版本，特别是针对执行时间错误，它可以与 LLVM/OpenMP GPU 记录和重放或简单的 GPU 加载器脚本结合使用，以更有效和高效地最小化 GPU 测试用例。

预期成果

一个在不丢失原始错误的情况下减少 GPU 错误的工具。可选地，其他属性可能是缩减的重点，而不仅仅是错误。

已确认的导师及其联系方式

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

所需/期望的技能

必需

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

期望

• 编译器知识，包括数据流和控制流分析，是一个加分项。
• 具有调试和错误缩减技术（llvm-reduce）的经验将有所帮助

项目规模。

中等

如果可能，请给出简单、中等或困难的评级

中等

讨论区： URL

描述

现代 C++ 将并行算法定义为标准库的一部分，例如 `std::transform_reduce(std::execution::par_unseq, vec.begin(), vec.end(), 0, std::plus, …)`。在这个项目中，我们希望扩展这些算法的实现，该实现使用 OpenMP，包括 GPU 卸载（如果合理）。虽然一些算法可能适合通过纯（包装器）运行时解决方案进行 GPU 卸载，但我们知道其他算法，特别是那些具有用户提供的 functor 的算法，还需要静态程序分析，并可能需要转换以进行额外的数据管理。该项目的目标是探索不同的算法以及我们在主机以及加速器设备（特别是 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 代码的经验。

项目规模。

大型

如果可能，请给出简单、中等或困难的评级

中等

讨论区： URL

描述

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)。它构建在 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) 以更高的优化级别第二次编译它们，因此得名“重新优化”。

对于这个问题的两个部分，有很多可能的方法。例如，可以通过采样、使用现有的分析基础设施或通过实施自定义检测来识别热函数。重新优化可以应用于整个函数，或者可以使用 outlining 来启用函数部分的优化。从 JIT 代码重新进入 JIT 基础设施可以在现有的惰性编译之上实现，或者通过自定义路径实现。

无论采用何种设计，目标是基础设施应该是通用的，以便可以被其他 LLVM API 客户端使用，并且应该支持进程外 JIT 编译（因此一些解决方案将在 ORC 运行时中实现）。

预期结果

• 改进间接引用的工效学 - 理想情况下，所有形式的间接引用（用于重新优化、惰性编译和过程链接表）都应该能够在运行时共享单个存根（和/或二进制重写元数据）。
• 在整理后的间接引用之上实现基本重新优化。
• （延伸目标）垃圾回收不再需要的未优化代码，一旦优化的版本可用。

期望技能： 中级 C++；理解 LLVM，特别是 LLVM JIT。

项目规模： 大型。

难度： 中等

已确认导师： Vassil Vassilev、Lang Hames

讨论区： URL

项目描述： JITLink 是 LLVM 新的 JIT 链接器 API——将编译器输出（可重定位目标文件）转换为内存中可执行字节的低级 API。为此，JITLink 的通用链接器算法需要专门化以支持目标对象格式（COFF、ELF、MachO）和架构（arm、arm64、i386、x86-64）。LLVM 已经为 MachO/arm64、MachO/x86-64、ELF/x86-64、ELF/aarch64 和 COFF/x86-64 提供了成熟的 JITLink 实现，而 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 或 passes 可以执行转换。
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 使用增量编译模式，最初开发它是为了在 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 代码库的经验，因为提到的问题可能在代码库的各个部分都有其根本原因。
• 最好是已经可以工作的本地 LLVM 构建

项目类型： 中等/200 小时

讨论区 URL

项目描述： Clang 编译器是 LLVM 编译器基础设施的一部分，支持各种语言，如 C、C++、ObjC 和 ObjC++。LLVM 和 Clang 的设计使它们可以用作库，并导致创建了整个编译器辅助工具生态系统。Clang 相对友好的代码库和 LLVM 中 JIT 基础设施的进步进一步促进了对处理 C++ 的不同方法的研究，模糊了编译时间和运行时间之间的界限。挑战包括增量编译和将编译/链接时间优化融入更动态的环境。

增量编译管道通过构建不断增长的翻译单元来逐块处理代码。然后将代码降低到 LLVM IR 中，并随后由 LLVM JIT 运行。这样的管道允许创建高效的解释器。该解释器支持交互式探索，并使 C++ 语言更用户友好。交互式 C++ 解释器 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 运行。这样的管道允许创建高效的解释器。该解释器支持交互式探索，并使 Jupyter 中通过 xeus 内核协议使用的交互式 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”输出以包含有关幸存符号的信息。

已确认导师： 普拉布·拉贾塞卡兰 彼得·霍塞克

讨论区： URL

描述: MLIR 的 Presburger 库 FPL (https://grosser.science/FPL) 为多面体编译和分析提供数学抽象。该库提供的主要抽象是由仿射不等式约束系统定义的整数元组集合。该库支持对此类集合的标准集合运算。结果将是由另一个约束系统定义的集合，可能具有更多约束。当按顺序执行许多集合运算时，约束系统可能会变得非常大，从而对性能产生负面影响。有几种潜在的方法可以简化约束系统；然而，这涉及执行额外的计算。因此，花费更多时间进行更积极的简化可能会使每个单独的操作变慢，但与此同时，由于约束系统大小的爆炸式增长，不充分的简化可能会使操作序列变慢。该项目的目标是找到两者之间的正确平衡。

该项目的目标

• 了解库在运行时和输出大小方面的性能。
• 通过找到最佳输出大小和性能权衡来优化库。

预期成果:

• 对库的主要操作的性能和输出约束复杂度进行基准测试。
• 实施简化启发式方法。
• 更好地理解哪些简化启发式方法可以充分提高整体性能，从而值得额外的计算成本。

理想技能：中级 C++，基准测试经验

项目规模：大型

难度：中等

已确认导师： 昆瓦尔·格罗弗

讨论区： URL

描述：该项目旨在为 MLIR 开发一种交互式查询语言，使开发人员能够动态查询 MLIR IR。该工具将提供 REPL（或命令行）界面，使用户能够查询 MLIR 代码的各种属性，例如“isConstant”和“resultOf”。拟议的工具旨在类似于 clang-query，它允许开发人员使用具有自动完成和其他功能的 TUI 匹配 C++ 代码中的 AST 表达式。

该项目的目标

• 了解 MLIR IR 表示形式以及用户进行的常见探索。
• 实施 REPL 以执行 MLIR IR 上的查询。

预期成果:

• 可用于交互式探索 IR 的独立工具。
• 实施该工具可使用的常用匹配器。
• （扩展）启用将查询匹配的 IR 部分提取到独立的 IR 代码片段中。

理想技能：中级 C++，编写/调试窥孔优化的经验

项目规模：中型或大型。

难度：中等

已确认导师： 雅克·皮纳尔

讨论区： URL

项目描述 我们正在实际部署中使用机器引导的编译器优化（“MLGO”）进行寄存器分配驱逐和内联以实现尺寸优化。ML 模型已通过强化学习算法进行训练。扩展到更多性能领域目前受到我们性能估计模型预测质量差的阻碍。改进这些模型对于强化学习训练算法的有效性至关重要，因此对于系统地将 MLGO 应用于更多优化至关重要。

项目规模： 175 或 350 小时。

难度： 中等

技能： C/C++，一些编译器经验，一些 Python。ML 经验是加分项。

预期成果：通过包含额外的运行时/分析信息（例如额外的 PMU 数据、LLC 未命中概率或分支误预测）来更好地建模执行环境。这涉及 (1) 构建一个涵盖额外运行时信息的数据收集管道，(2) 修改 ML 模型以允许处理此数据，以及 (3) 修改模型的训练和推理过程以使用此数据。

如今，这些模型几乎纯粹是静态分析；它们查看指令，但它们对执行环境和代码的运行时行为做出一刀切的假设。该项目的目标是从静态分析转向更动态的模型，以更好地表示代码的实际执行方式。

导师 Ondrej Sykora, Mircea Trofin, Aiden Grossman

讨论区 URL

项目描述： Clang 静态分析器附带了污点分析的实验性实现，这是一种面向安全的分析技术，旨在警告用户关于攻击者控制的（“污点”）数据流入敏感函数的情况，如果攻击者能够伪造正确的输入，这些函数可能会表现出意外和危险的行为。程序员可以通过正确“清理”污点数据来解决此类警告，以消除这些危险输入。可以使用这种方法捕获的一个常见问题是 SQL 注入。一个更简单的例子，可以说与 Clang 用户更相关，是由于攻击者控制的数字用作循环边界而在堆栈或堆数组上迭代或作为参数传递给低级缓冲区操作函数（例如memcpy().

作为静态符号执行引擎，静态分析器通过简单地维护在符号模拟期间从已知污点源获得的“符号”（命名的未知数值）列表来实现污点分析。然后，这些符号被视为可能采用任意具体值，而不是采用未知可能值子集的一般情况。例如，除以未经检查的未知值不一定保证除零警告，因为通常不知道该值是否可以为零。但是，除以未经检查的污点值会立即保证除零警告，因为攻击者可以自由地传递零作为输入。因此，静态分析器的污点基础设施由几个部分组成：有一种机制用于跟踪符号程序状态中的污点符号，有一种方法可以定义新的污点源，并且一些路径敏感检查被教导消耗污点信息以发出额外的警告（如除零检查器），充当污点“接收器”并定义特定于检查器的“清理”条件。

整个设施都被标记为实验性的：它基本上是一个概念验证实现。它很可能可以做得非常好，但它需要通过在真实世界的源代码上运行来进行一些质量控制，并且在我们可以声明它稳定之前，需要解决许多错误，尤其是在个别检查中。此外，最吸引人的检查——基于污点循环边界或大小参数的缓冲区溢出检测——从未实现。还有一个相关的检查，用于使用污点索引进行数组访问——这再次是实验性的；让我们看看我们是否也可以宣布这个稳定！

预期结果： 默认情况下为静态分析器的所有用户启用了许多与污点相关的检查，或者作为选择加入提供给关心安全性的用户。它们被证实对真实世界的代码具有低误报率。希望缓冲区溢出检查是其中之一。

理想技能： 中级 C++，能够理解 LLVM 代码。我们还将在一些纯 C 代码上运行我们的分析。编译器或安全方面的背景知识是受欢迎的，但不是绝对必要的。

项目规模： 中型或大型。

难度： 中等

已确认导师： Artem Dergachev, Gábor Horváth, Ziqing Luo

讨论区： URL

项目描述 这项工作延续了 GSoC 2020 和 2021 的工作。开发人员通常使用标准优化流程（如 -O2 和 -O3）来优化他们的代码。手动制作的启发式方法用于确定要选择哪些优化pass以及如何排序这些pass的执行。然而，此过程并非针对特定程序或程序类型量身定制，因为它旨在对任何输入执行“相当好”。我们希望改进现有的启发式方法，或用基于机器学习的模型替换启发式方法，以便 LLVM 编译器可以为每个程序提供更优越的pass顺序。最后一个里程碑启用了特征提取，并开始研究训练策略以选择更合适的pass流程。

项目规模： 175 或 350 小时。

难度： 中等

技能： C/C++，一些编译器经验。ML 经验是加分项。

预期成果：预训练模型，选择最经济的优化流程，且性能无损失；在 LLVM 中挂钩模型；（重新）训练工具；通过搜索或学习提出新的优化序列。

导师 Tarindu Jayatilaka, Mircea Trofin, Johannes Doerfert

讨论区 URL

项目描述
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 仓库代码覆盖率报告中显示此功能的使用情况。

项目规模： 中等或大型

难度： 中等

已确认导师： 古尔芬·萨夫伦·耶尼切里 彼得·霍塞克

讨论区： URL

项目描述 开发人员经常使用编译器生成的备注和分析报告来优化他们的代码。虽然编译器通常擅长在生成的消息中包含源代码位置（即行号和列号），但如果这些生成的消息还包括相应的源代码级表达式，则会很有用。LLVM 实现中使用的方法是使用一小组内在函数来定义 LLVM 程序对象和源代码级表达式之间的映射。该项目的目标是使用这些内在函数中包含的信息来生成与 LLVM 值相对应的源表达式，或者在现有信息不足的情况下提出和实施解决方案以获得相同的结果。优化程序中的内存访问对于应用程序性能非常重要。我们特别打算使用编译器分析消息，这些消息报告与 LLVM 加载/存储指令相对应的源代码级内存访问，这些指令会抑制编译器优化。例如，我们可以使用此信息来报告抑制向量化的内存访问依赖关系。

项目规模： 中等

难度： 中等

技能： 中级 C++，熟悉 LLVM 核心或愿意学习它。

预期结果： 提供一个接口，该接口接受 LLVM 值并返回与等效源代码级表达式相对应的字符串。我们特别感兴趣的是使用此接口将加载/存储指令中使用的地址映射到等效的源代码级内存引用。

已确认导师： Satish Guggilla (satish.guggilla@intel.com) Karthik Senthil (karthik.senthil@intel.com)

讨论区： URL

    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.
    }