Welcome prospective Google Summer of Code 2025 Students! This document is your starting point to finding interesting and important projects for LLVM, Clang, and other related sub-projects. This list of projects is not only developed for Google Summer of Code, but open projects that really need developers to work on and are very beneficial for the LLVM community.

We encourage you to look through this list and see which projects excite you and match well with your skill set. We also invite proposals not on this list. More information and discussion about GSoC can be found in discourse . If you have questions about a particular project please find the relevant entry in discourse, check previous discussion and ask. If there is no such entry or you would like to propose an idea please create a new entry. Feedback from the community is a requirement for your proposal to be considered and hopefully accepted.

The LLVM project has participated in Google Summer of Code for many years and has had some very successful projects. We hope that this year is no different and look forward to hearing your proposals. For information on how to submit a proposal, please visit the Google Summer of Code main website.

Description

Use the variable location information from the debug info to annotate LLDB’s disassembler (and `register read`) output with the location and lifetime of source variables. The rich disassembler output should be exposed as structured data and made available through LLDB’s scripting API so more tooling could be built on top of this. In a terminal, LLDB should render the annotations as text.

Expected outcomes

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

using the debug information that LLDB also has access to (observe how the source variable i is in r15 from [0x100000f77+slide))

$ 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

The goal would be to produce output like this for a subset of unambiguous cases, for example, variables that are constant or fully in registers.

Confirmed mentors and their contacts

• Adrian Prantl aprantl@apple.com (primary contact)
• Jonas Devlieghere jdevlieghere@apple.com

Required / desired skills

Required:

• Good understanding of C++
• Familiarity with using a debugger on the terminal
• Need to be familiar with all the concepts mentioned in the example above
• Need to have a good understanding of at least one assembler dialect for machine code (x86_64 or AArch64).

Desired:

• Compiler knowledge including data flow and control flow analysis is a plus.
• Being able to navigate debug information (DWARF) is a plus.

Size of the project:

medium (~175h)

Project difficulty:

hard

Discourse: URL

Description:

Bfloat16 is a recently developed floating point format tailored to machine learning and AI, and in the latest C++23 standard, it is officially standardized as std::bfloat16_t. Its support could be found in many modern hardware, ranging from CPUs of all the major vendors including Intel, AMD, Apple, and Amazon, to GPUs (nVidia and AMD GPUs) and Google TPUs. On the software side, it is supported in all major accelerator libraries, such as CUDA, ROCm, oneAPI, PyTorch, and Tensorflow. The goal for this project is to implement bfloat16 math functions in the LLVM libc library.

Expected result:

• Setup the generated headers properly so that the type and the functions can be used with various compilers (+versions) and architectures.
• Implement generic basic math operations supporting bfloat16 data types that work on supported architectures: x86_64, arm (32 + 64), risc-v (32 + 64), and GPUs.
• Implement specializations using compiler builtins or special hardware instructions to improve their performance whenever possible.
• If time permits, we can start investigating higher math functions for bfloat16.

Skills:

Basic C & C++ skills + Interest in knowing / learning more about the delicacy of floating point formats.

Project size: Large

Difficulty: Easy/Medium

Confirmed Mentors: Tue Ly, Nicolas Celik,

Discourse: URL

Description:

Modern GPUs are capable of unified addressing with the host. We currently use this to provide I/O support using the RPC interface. However, this requires a dedicated user thread on the CPU to handle the server code. We want to explore alternatives to providing I/O from the GPU using the Linux io_uring interface.

This interface is a ring buffer designed to accelerate syscalls. However, it provides a polling mode that allows the kernel to flush the ring buffer without the user initiating a system call. We should be able to register mmap() memory with the GPU using AMD and NVIDIA API calls. This interface should allow us to implement a rudimentary read/write interface which can be thought of as the same as the syscall on the CPU. That can then be used to implement a whole file interface.

Expected result:

• An implementation of pwrite and pread that runs on the GPU.
• Support for printf by forwarding snprintf into pwrite.
• If time permits, exploring GPU file APIs.

Skills:

Basic C & C++ skills + access to a GPU, Linux kernel knowledge, GPU knowledge.

Project size: Small

Difficulty: Hard

Confirmed Mentors: Joseph Huber, Tian Shilei

Discourse: URL

Description:

The LLVM C library provides implementations of math functions. We want to profile these against existing implementations, such as CUDA's libdevice, ROCm's device libs, and OpenCL's libclc. Last year we worked on some interfaces to support these tests, now they need to be refined and filled out for the interesting functions.

Additionally, we want to verify the accuracy of these functions when run on the GPU via brute force testing. The goal is to verify that the implementations are correct and at least conformant to the error ranges in the OpenCL standard. This will require a set of unit tests written in the offload/ project, ideally using the new API that @callumfare is working on.

Expected result:

• Final performance results similar to Old results but with the more optimized functions and higher accuracy.
• A test suite that can do brute force testing to confirm that the implementations are conformant.

Skills:

Basic C & C++ skills + access to a GPU, some math knowledge

Project size: Small

Difficulty: Easy / Medium

Confirmed Mentors: Joseph Huber, Tue Ly

Discourse: URL

Description: The ClangIR (CIR) project aims to establish a new intermediate representation (IR) for Clang. Built on top of MLIR, it provides a dialect for C/C++ based languages in Clang, and the necessary infrastructure to emit it from the Clang AST, as well as a lowering path to the LLVM-IR dialect. ClangIR upstreaming is currently in progress.

In order to give community more frequent updates it'd be great if we can report ClangIR progress by measuring the coverage of existing Clang's CodeGen tests in face of a ClangIR enabled pipeline. By collecting information on crashing, passing or failing tests we can come up with a metric that is easier to report and understand, provide entry points for newcomers looking for tasks and help the project by classifying existing issues. Existing Clang CodeGen tests live in clang/test/CodeGen* and can be found in different states regarding ClangIR support:

• FileCheck fails. LLVM IR builds but FileCheck fails to match output
  • LLVM IR differs because ClangIR pipeline is emitting different IR (e.g. different instructions are used, missing attributes). Issues need to be created and ClangIR needs to be fixed.
  • LLVM IR differs because CHECK lines need be made more flexible (LLVM-IR dialect output is different, SSA value names, order of attributes, etc). It's possible a tool like llvm-canon might be of good use here.
• Test crash / error. ClangIR doesn't support some C/C++ construct or LLVM lowering hasn't been implemented.
• Test pass. Yay!

In order to retrieve the information above, the student needs to make changes to Clang's testing infra (LIT configs, scripts, tests, ???) such that it's easier to replay the same invocations with ClangIR enabled, compare against traditional pipeline result or retrieve special directives from tests.

It's not clear what is the best methodology just yet, but it's expected that submitted proposals that want to be taken seriously should present few possible ideas on how to achieve this, prior discussion with other members of the community is encouraged. The student is also expected to interact with the ClangIR community, file github issues, investigate and/or make changes to failing codegen tests.

Expected result:

1. Build the infrastructure to run tests and collect results.
2. Present the results in a way that can be placed on a webpage.
3. File issues or change check lines for 50% of the "FileCheck fails" category above. The only subdirectories that need consideration for the moment are:

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

• Bonus point: find ways to automate/facilitate changes to tests, put PRs to fix problems in ClangIR.

Skills: Python, intermediate C++ programming skills and familiarity with basic compiler design concepts are required. Prior experience with LLVM IR, MLIR, Clang or ClangIR programming is a big plus, but willingness to learn is also a possibility.

Project size: Large

Difficulty:Medium

Potential Mentors: Bruno Cardoso Lopes Andy Kaylor

Discourse: URL

Description: ClangIR is a new, MLIR_based intermediate representation of C and C++ code. It has been developed in an LLVM incubator project, but work is now underway to migrate the code from the incubator to the main LLVM repository. As the code is moved, it must be updated to align with LLVM coding standards and quality expectations. The goal for this project is to participate in the ClangIR upstreaming process and help improve both the code and the upstreaming process.

The ClangIR project intends to unlock the possibility of better optimization, analysis, and diagnostics for C and C++ code by adding new abstractions that more closely model the source constructs, preserving more details than are available in standard LLVM IR. The ClangIR dialect is already being used to solve real-world problems using the implementation available in the ClangIR incubator, but we need to move this into the main LLVM repository in order to make this functionality available to a larger audience.

This project will be an opportunity to gain hands-on experience with MLIR development with a focus on day-to-day software engineering discipline. Participants will work side-by-side with other LLVM contributors to achieve a common goal, and in the process will gain a deep understanding of the ClangIR dialect.

Expected result:

1. Migrate ClangIR support for C and C++ language features into the main LLVM repository
2. Improve the quality of code as it is being migrated
3. Suggest ways to improve the migration process

Skills: Proficiency with modern C++ programming and familiarity with basic compiler design concepts are required. Prior experience with LLVM IR, MLIR, Clang or ClangIR programming is a big plus, but since the goal of this project is to gain such experience, it is not a prerequisite.

Project size: Medium to Large

Difficulty:Medium

Potential Mentors: Andy Kaylor Bruno Cardoso Lopes

Discourse: URL

Description: The Clang Static Analyzer (CSA) can already find a wide range of temporal memory errors. These checks often have hardcoded knowledge about the behavior of some APIs. For example, the cplusplus.InnerPointer checker knows the semantics of std::string::data. The Clang community introduced some lifetime annotations including [[clang::lifetimebound]] and [[clang::lifetime_capture_by(X)]] and made many improvements to Clang's default warnings. Unfortunately, the compiler's warnings only do statement local analysis. The CSA is capable of advanced inter-procedural analysis. Generalizing the existing checks like cplusplus.InnerPointer could enable the analyzer to find even more errors in annotated code. This can become even more impactful once the standard library gets annotated.

Expected result:

1. Identify the checks that can benefit from the [[clang::lifetimebound]] and [[clang::lifetime_capture_by(X)]] annotations.
2. Extend those checks to support these annotations.
3. Make sure the generated bug reports are high quality, the diagnostics properly explain how the analyzer took these annotations into account.
4. Validate the results on real world projects.
5. Potentially warn about faulty annotations (stretch goal).

Skills: Intermediate C++ programming skills and familiarity with basic compiler design concepts are required. Prior experience with Clang or CSA programming is a big plus, but willingness to learn is also a possibility.

Project size: Large

Difficulty:Hard

Potential Mentors: Gabor Horvath Balazs Benics Daniel Domjan

Discourse: URL

Description

Currently there is no easy way to take a collection of source files using C++20 modules and build an executable from them. This makes it hard to create simple tests or tiny programs using C++20 modules without first setting up a build system. This project's goal is to extend the extremely simple build system in Clang's driver to handle these cases.

This can be done by using Clang's existing support for scanning for C++20 modules to discover the dependencies between the source files that have been passed in, and then build them in that order, passing in the right PCM files where needed. This may also be extended to support explicitly building Clang modules discovered via module map files too.

Expected outcomes

Invoking clang similarly to

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

Confirmed mentors and their contacts

• Michael Spencer

Required skills

Intermediate knowledge of C++; familiarity with how C++ code is built. Familiarity with C++20 modules is an asset, but not required.

Size of the project:

medium (~175h)

Project difficulty:

medium

Discourse: URL

Description

Undefined Behavior Sanitizer (UBSan) is a useful compilation mode in Clang for finding uses of undefined behavior (e.g. signed integer overflow) and problematic C/C++ code (e.g. unsigned integer overflow). The default version of UBSan uses a compiler runtime that only works in userspace (e.g. it won’t work in the kernel or for embedded applications) and is not considered secure enough for use in production environments. To handle these other environments UBSan provides a trapping mode that emits trap instructions that immediately halts the application rather than calling into the UBSan runtime which normally diagnoses the problem and then carries on execution.

Unfortunately trapping UBSan has some deficiencies which make it hard to use. In particular:

• Clang silently ignores the -fsanitize-trap=undefined flag when it's passed without -fsanitize=undefined. This project would fix this as a “warm up task” to get familiar with the Clang codebase.
• When a UBSan trap is hit with the debugger attached it is not convenient to figure out the reason UBSan trapped. For x86_64 and arm64 some information is encoded in the instruction but decoding this is very inconvenient. While LLDB could be taught to look at the instruction and decode the meaning this is brittle because it depends on undocumented compiler ABI. Instead we can build upon the __builtin_verbose_trap work to encode the reason for trapping ("trap reasons") inside the debug information. If time permits we can also investigate emitting more precise trap reasons

Expected outcomes

• When the -fsanitize-trap=undefined flag is passed on its own the compiler silently ignores it. Currently Clang requires that the -fsanitize-trap= flag is also passed. Clang should be taught to warn about this.
• Teach Clang to emit the UBSan trap reasons in debug information on UBSan trap instructions similar to how __builtin_verbose_trap works.
• Confirm LLDB is able to recognize the UBSan trap reasons and add tests for this.
• If time permits we should investigate emitting more precise trap reasons by using information available in the compiler. We may want to implement a "Sema Diagnostic" like approach where trap reason strings can easily be constructed inside the compiler. This task is more open-ended and has potentially uses outside of UBSan (e.g. -fbounds-safety).

Confirmed mentors and their contacts

• Dan Liew
• Michael Buch

Required skills

Good understanding of C++

Desirable skills

• Familiarity with UBSan
• Familiarity with LLDB

Size of the project:

small (~90h). but can be extended if time allows

Project difficulty:

Easy. This project would be good for a beginner to LLVM. Note the "emitting more precise trap reasons" portion is more open ended and so the difficulty of this is entirely down to direction the applicant chooses.

Discourse: URL

Description of the project: Clang-Doc is a C/C++ documentation generation tool created as an alternative for Doxygen and built on top of LibTooling. This effort started in 2018 and critical mass has landed in 2019, but the development has been largely stagnant mostly due to a lack of resources until last year when the development restarted as a successful Google Summer of Code project.

The tool is built on top of LibTooling and leverages Clang parsers which supports parsing of Doxygen commands in documentation comments (this support is also used in the implementation of Clang’s

-Wdocumentation

• Not all Doxygen commands are supported, limiting the Clang-Doc’s usability.
• Not all C/C++ constructs are currently handled, most notably C++20 features such as concepts.
• Markdown support in documentation comments introduced in Doxygen version 1.8.0 is missing.

Expected result: The goal of this project is to implement the missing features in Clang’s documentation parser as well as their handling in Clang-Doc to improve the quality of the generated documentation. The eventual goal is for the LLVM project to start using Clang-Doc for generating its reference documentation, but before we can do that we need to ensure that all required features are implemented.

Successful proposals should focus not only on addressing the existing limitations, but also draw inspiration for other potential improvements from other documentation tools such as hdoc, standardese, subdoc or cppdocgen.

Over the course of the project, the candidate will have an opportunity to gain significant experience with LLVM and Clang internals (including lexer and parser) and C/C++ language.

Skills: Intermediate knowledge of C++; interest in compilers and parsers. Previous experience with Clang/LibTooling is a bonus but not required.

Project size: Either medium or large.

Difficulty: Medium

Confirmed Mentor: Petr Hosek, Paul Kirth

Discourse: URL

Description of the project: The Clang compiler is part of the LLVM compiler infrastructure and supports various languages such as C, C++, ObjC and ObjC++. The design of LLVM and Clang enables them to be used as libraries, and has led to the creation of an entire compiler-assisted ecosystem of tools. The relatively friendly codebase of Clang and advancements in the JIT infrastructure in LLVM further enable research into different methods for processing C++ by blurring the boundary between compile time and runtime. Challenges include incremental compilation and fitting compile/link time optimizations into a more dynamic environment. Incremental compilation pipelines process code chunk-by-chunk by building an ever-growing translation unit. Code is then lowered into the LLVM IR and subsequently run by the LLVM JIT. Such a pipeline allows creation of efficient interpreters. The interpreter enables interactive exploration and makes the C++ language more user friendly. Clang-Repl is one example.

Expected result: The project aims to develop a robust mechanism for resolving missing symbols by dynamically identifying and loading the appropriate shared objects or static archives. Additionally, it will explore use cases where adapting symbols based on execution profiles leads to measurable performance improvements, optimizing the efficiency of just-in-time compilation and dynamic execution environments.

Skills: Intermediate knowledge of C++, Understanding of LLVM and the LLVM JIT in particular

Project size:Either medium or large.

Difficulty: Medium

Confirmed Mentor: Vassil Vassilev

Discourse: URL

Description

Enzyme requires good information about the memory layout of types. LLVM-IR is intentionally opaque, e.g. `&f32` and `&f64` both have the LLVM-IR type `ptr`. Enzyme is generally able to infer the underlying type (e.g. f32 vs f64) through usage analysis, but that process is slow and can in some cases fail. To make autodiff more robust, we should lower either MIR or THIR type information into LLVM-IR metadata. This analysis is recursive, for example `&[T]` is a fat pointer and therefore will be represented as a (ptr, int) pair in LLVM-IR. In this case the algorithm should recursively also analyze `T` and generate metadata for it.

The function here can be extended to generate metadata from rusts Mid-level IR (MIR). A prototype of the parser was implemented here and can be used for inspiration. Various LLVM-IR examples for the metadata which we want to generate can be found in this test folder. Look for annotations in the style of ` {[-1]:Pointer, [-1,0]:Float@float}`.

The online compiler Explorer fork can be used to trigger related bugs, starting with "can not deduce type of X".

Expected outcomes

The participant should find and select some interesting testcases, in which Enzyme either fails to differentiate an example due to inssuficient Type Information, or takes unreasonable long times (e.g. > 20x slower than compiling the code without autodiff). In the second case, a profiler should be used to verify that Enzyme causes a long compile time due to type analysis. The participant should then write (or later extend) the Type parser to generate the correct metadata, such that Enzyme can handle the new testcases. The LIT testcases should be added to the rust compiler, to avoid further regressions.

Examples for code that currently is not handled correctly can be discussed in the project proposal phase.

Confirmed mentors and their contacts

• Manuel Drehwald
• Oli Scherer
• Johannes Doerfert

Required skills

Intermediate knowledge of Rust and C++; Familiarity with profilers or LLVM metadata is an asset, but not required.

Size of the project:

medium (~175h)

Project difficulty:

medium

Discourse: URL

Description: Currently, every LLVM-based frontend that wants to support calling into C code (FFI) needs to re-implement a substantial amount of complex call ABI handling. The goal of this project is to introduce an LLVM ABI library, which can be reused across different frontends, including Clang. More details on the motivation and a broad outline of the design are available in the corresponding RFC.

The initial phase of the project will be to implement a prototype that can handle at least the x86_64 System V ABI. This will involve implementing the ABI type system, mapping of Clang types to ABI types and moving at least part of the X86 ABIInfo implementation from Clang to the new ABI library. This is to demonstrate general feasibility, figure out design questions and analyze compilation-time impact.

Assuming the results from the prototype are positive, the next step would be to upstream the implementation by splitting it into smaller PRs. Finally, the implementation can be expanded to cover additional targets, ultimately removing Clang's ABI handling code entirely.

Expected result: The minimum result is a prototype for the x86_64 ABI. The maximum result is fully upstreamed support for all targets. The expected result is somewhere in the middle between those two.

Skills: Intermediate C++. Some familiarity with LLVM is a plus, but not required.

Project size: Large

Difficulty: Hard

Confirmed mentors: Nikita Popov

Discourse: URL

Description: LLVM IR can't represent implementations of memcpy, memcmp, etc correctly due to the lack of a way to represent raw memory. This project aims to add a new 'byte' type to the LLVM IR to represent raw memory.

In addition to adding the new type, the project involves changing clang to lower chars to the new b8 type instead of i8, fixing incorrect lowerings of memory intrinsics, and tracking down the performance regressions.

There is already a prototype implementation of the byte type for an older version of LLVM. More information here.

Expected result: The minimum result is a port of the existing prototype to the current LLVM, fixing all known incorrect optimizations, add support for the byte type to Alive2, and a performance analysis.

Skills: Intermediate C++, familiarity with LLVM, profiling.

Project size: Large

Difficulty: Hard

Confirmed mentors: Nuno Lopes

Discourse: URL

Description: LLVM offers different information via remarks, profiling, or runtime debug annotations (e.g., LIBOMPTARGET_INFO=-1). However, as projects increase, dissecting this information becomes difficult for users. For example, it is difficult to collect all this data, visualize it, and learn from it when building large projects.

Currently, some of this information—for example, compilation remarks—can be exported in JSON format. We want to create a tool to visualize, aggregate, and summarize the information. To aid accelerator development, we will start with the offload project as the primary candidate.

Similar tools, such as opt-viewer, can be used as references and starting points.

Expected outcomes: The expected outcome is a tool (e.g., in the form of a compiler wrapper such as ccache) that will allow the dump of all the compiler-generated information in JSON format and organize it in a project structure.

The tool should generate an HTML-based report to help visualize the remarks. We envision a small client-server application using Python to spawn a local server as the visualization's front end. The server will expose the different reports and perform early analysis and aggregation.

Additionally, the tool should be designed so that, in the future, the analysis of the remarks can provide generalized guidelines for the developer (e.g., show the most common remark, use LLM models to explain actions, etc.). The client (HTML viewer) will display the aggregated data, in-line remarks, profile information, etc. We do not expect the project to have all the features at the end of the GSoC but to serve as a placeholder for growth in the future.

In particular, the outcomes of this project should be:

• Together with the mentors, help the design of the compiler wrapper, data storage layer, and client/server infrastructure. This includes the server API. The outcome of this task is a design document (similar to an RFC).
• Create a compiler wrapper that will dump different information in JSON format into the data storage layer (e.g., folders).
• Create a simple server layer that exposes the backend API to the front end. Python is the right way to do this, but we welcome other suggestions that align with the LLVM project. We would like to avoid relying on external projects (e.g., Flask) to avoid adding more dependencies to the LLVM project.
• Create a simple client-side visualization tool that can be extended in the future to show more reports.

Mentors: @shiltian, @jdoerfert, @josemonsalve2

Required/desired skills:

• Basic understanding of the LLVM Compiler to be able to generate compiler remarks, profiling data, and other information from the compiler.
• Proficiency in Python and C++.
• Full-stack web development.

Project size: Large

Difficulty: Easy

Discourse Link: [GSoC][Offload]LLVM Compiler Remarks Visualization Tool for Offload Proposal

Google Summer of Code 2024 was yet another successful one for LLVM project. For the list of accepted and completed projects, please take a look into Google Summer of Code website.

Welcome prospective Google Summer of Code 2024 Students! This document is your starting point to finding interesting and important projects for LLVM, Clang, and other related sub-projects. This list of projects is not only developed for Google Summer of Code, but open projects that really need developers to work on and are very beneficial for the LLVM community.

We encourage you to look through this list and see which projects excite you and match well with your skill set. We also invite proposals not on this list. More information and discussion about GSoC can be found in discourse . If you have questions about a particular project please find the relevant entry in discourse, check previous discussion and ask. If there is no such entry or you would like to propose an idea please create a new entry. Feedback from the community is a requirement for your proposal to be considered and hopefully accepted.

The LLVM project has participated in Google Summer of Code for several years and has had some very successful projects. We hope that this year is no different and look forward to hearing your proposals. For information on how to submit a proposal, please visit the Google Summer of Code main website.

Description of the project: Many of LLVM's unit tests have been reduced automatically from larger tests. Previous-generation reduction tools used undef and poison as placeholders everywhere, as well as introduced undefined behavior (UB). Tests with UB are not desirable because 1) they are fragile since in the future the compiler may start optimizing more aggressively and break the test, and 2) it breaks translation validation tools such as Alive2 (since it's correct to translate a fuction that is always UB into anything).
The major steps include:

1. Replace known patterns such as branch on undef/poison, memory accesses with invalid pointers, etc with non-UB patterns.
2. Use Alive2 to detect further patterns (by searching for tests that are always UB).
3. Report any LLVM bug found by Alive2 that is exposed when removing UB.

Expected result: The majority of LLVM's unit tests will be free of UB.

Skills: Experience with scripting (Python or PHP) is required. Experience with regular expressions is encouraged.

Project size: Either medium or large.

Difficulty: Medium

Confirmed Mentor: Nuno Lopes

Discourse: URL

Description of the project: The existing file that describes the SPIR-V instruction set in LLVM was manually created and is not always complete or up to date. Whenever new instructions need to be added to the SPIR-V backend, the file must be amended. In addition, since it is not created in a systematic way, there are often slight discrepancies between how an instruction is described in the SPIR-V spec and how it is declared in the TableGen file. Since SPIR-V backend developers often use the spec as a reference when developing new features, having a consistent mapping between the specification and TableGen records will ease development. This project proposes creating a script capable of generating a complete TableGen file that describes the SPIR-V instruction set given the JSON grammar available in the KhronosGroup/SPIRV-Headers repository, and updating SPIR-V backend code to use the new definitions. The specific method used for translating the JSON grammar to TableGen is left up to the discretion of the applicant, however, it should be checked into the LLVM repository with well-documented instructions to replicate the translation process so that future maintainers will be able to regenerate the file when the grammar changes. Note that the grammar itself should remain out-of-tree in its existing separate repository.

Expected result:

• The SPIR-V instruction set's definition in TableGen is replaced with one that is autogenerated.
• A script and documentation are written that support regenerating the definitions as needed given the JSON grammar of the SPIR-V instruction set.
• Usage of the SPIR-V instruction set in the SPIR-V backend updated to use the new autogenerated definitions.

Skills: Experience with scripting and an intermediate knowledge of C++. Previous experience with LLVM/TableGen is a bonus but not required.

Project size: Medium (175 hour)

Confirmed Mentors: Natalie Chouinard, Nathan Gauër

Discourse: URL

Description of the project: The LLVM bitstream file format is used for serialization of intermediate compiler artifacts, such as LLVM IR or Clang modules. There are situations where multiple bitstream files store identical information, and this duplication leads to increased storage requirements.

This project aims to integrate the LLVM CAS library into the LLVM bitstream file format. If we factor out the frequently duplicated part of a bitstream file into a separate CAS object, we can replace all copies with a small reference to the canonical CAS object, saving storage.

The primary motivating use-case for this project is the dependency scanner that's powering "implicitly-discovered, explicitly-built" Clang modules. There are real-world situations where even coarse de-duplication on the block level could halve the size of the scanning module cache.

Expected result: There's a way to configure the LLVM bitstream writer/reader to use CAS as the backing storage.

Skills: Intermediate knowledge of C++, some familiarity with data serialization, self-motivation.

Project size: Medium or large

Confirmed Mentors: Jan Svoboda, Steven Wu

Discourse: URL

Description of the project: 3-way comparisons return the values -1, 0 or 1 depending on whether the values compare lower, equal or greater. They are exposed in C++ via the spaceship operator (operator<=>) and in Rust via the PartialOrd and Ord traits. Currently, such comparisons produce sub-optimal codegen and optimization results in some cases.

The goal of this project is to resolve these optimization issues by implementing new 3-way comparison intrinsics, as described in [RFC] Add 3-way comparison intrinsics. The implementation steps are broadly:

1. Add the intrinsics to LLVM IR.
2. Implement legalization/expansion support in SelectionDAG and GlobalISel.
3. Implement optimization support in ConstantFolding, InstSimplify, InstCombine, CorrelatedValuePropagation, IndVarSimplify, ConstraintElimination, IPSCCP, and other relevant transforms.
4. Make use of the intrinsics via InstCombine canonicalization or direct emission in clang/rustc.

Expected result: Support for the intrinsics in the backend and the most important optimization passes. Ideally full integration starting at the frontend.

Skills: Intermediate knowledge of C++

Project size: Medium or large

Difficulty: Medium

Confirmed Mentors: Nikita Popov, Dhruv Chawla

Discourse: URL

Description of the project: The llvm.org website serves as the central hub for information about the LLVM project, encompassing project details, current events, and relevant resources. Over time, the website has evolved organically, prompting the need for a redesign to enhance its modernity, structure, and ease of maintenance.

The goal of this project is to create a contemporary and coherent static website that reflects the essence of LLVM.org. This redesign aims to improve navigation, taxonomy, content discoverability, mobile device support, accessibility, and overall usability. Given the critical role of the website in the community, efforts will be made to engage with community members, seeking consensus on the proposed changes.

Expected result: A modern, coherent-looking website that attracts new prospect users and empowers the existing community with better navigation, taxonomy, content discoverability, and overall usability. Since the website is a critical infrastructure and most of the community will have an opinion this project should try to engage with the community building community consensus on the steps being taken. Suggested approach:

• Conduct a comprehensive content audit of the existing website.
• Select appropriate technologies, preferably static site generators like Hugo or Jekyll.
• Advocate for a separation of data and visualization, utilizing formats such as YAML and Markdown to facilitate content management without direct HTML coding.
• Present three design mockups for the new website, fostering open discussions and allowing time for alternative proposals from interested parties.
• Implement the chosen design, incorporating valuable feedback from the community.
• Collaborate with content creators to integrate or update content as needed.

Skills: Knowledge in the area of web development with static site generators. Knowledge in html, css, bootstrap, and markdown. Patience and self-motivation.

Difficulty: Hard

Project size: Large

Confirmed Mentors: Tanya Lattner, Vassil Vassilev

Discourse: URL

Description of the project: The Clang compiler is part of the LLVM compiler infrastructure and supports various languages such as C, C++, ObjC and ObjC++. The design of LLVM and Clang enables them to be used as libraries, and has led to the creation of an entire compiler-assisted ecosystem of tools. The relatively friendly codebase of Clang and advancements in the JIT infrastructure in LLVM further enable research into different methods for processing C++ by blurring the boundary between compile time and runtime. Challenges include incremental compilation and fitting compile/link time optimizations into a more dynamic environment.

Incremental compilation pipelines process code chunk-by-chunk by building an ever-growing translation unit. Code is then lowered into the LLVM IR and subsequently run by the LLVM JIT. Such a pipeline allows creation of efficient interpreters. The interpreter enables interactive exploration and makes the C++ language more user friendly. Clang-Repl is one example.

Clang-Repl uses the Orcv2 JIT infrastructure within the same process. That design is efficient and easy to implement however it suffers from two significant drawbacks. First, it cannot be used in devices which do not have sufficient resources to host the entire infrastructure, such as the arduino due (see this talk for more details). Second, crashes in user codes mean that the entire process crashes, hindering overall reliability and ease of use.

This project aims to move Clang-Repl to an out-of-process execution model in order to address both of these issues.

Expected result: Implement an out-of-process execution of statements with Clang-Repl; Demonstrate that Clang-Repl can support some of the ez-clang use-cases; Research into approaches to restart/continue the session upon crash; As a stretch goal design a versatile reliability approach for crash recovery;

Skills: Intermediate knowledge of C++, Understanding of LLVM and the LLVM JIT in particular

Project size:Either medium or large.

Difficulty: Medium

Confirmed Mentor: Vassil Vassilev,

Discourse: URL

Description of the project: The Clang compiler is part of the LLVM compiler infrastructure and supports various languages such as C, C++, ObjC and ObjC++. The design of LLVM and Clang allows the compiler to be extended with plugins[1]. A plugin makes it possible to run extra user defined actions during a compilation. Plugins are supported on unix and darwin but not on windows due to some specifics of the windows platform.

This project would expose the participant to a broad cross section of the LLVM codebase. It involves exploring the API surface, classifying the interfaces as being public or private, and annotating that information to the API declarations. It would also expose the participant to details and differences of different platforms as this work is cross-platform (Windows, Linux, Darwin, BSD, etc). The resulting changes would improve LLVM on Linux and Windows while enabling new functionality on Windows.

Expected result: This project aims to allow make clang -fplugin=windows/plugin.dll work. The implementation approach should extend the working prototype [3] and extend the annotation tool [4]. The successful candidate should be prepared to attend a weekly meeting, make presentations and prepare blog posts upon request.

Further reading
[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

Skills: Intermediate knowledge of C++, Experience with Windows and its compilation and linking model.

Project size:Either medium or large.

Difficulty: Medium

Confirmed Mentor: Vassil Vassilev, Saleem Abdulrasool

Discourse: URL

Description of the project: Clang, like any C++ compiler, parses a sequence of characters as they appear, linearly. The linear character sequence is then turned into tokens and AST before lowering to machine code. In many cases the end-user code uses a small portion of the C++ entities from the entire translation unit but the user still pays the price for compiling all of the redundancies.

This project proposes to process the heavy compiling C++ entities upon using them rather than eagerly. This approach is already adopted in Clang’s CodeGen where it allows Clang to produce code only for what is being used. On demand compilation is expected to significantly reduce the compilation peak memory and improve the compile time for translation units which sparsely use their contents. In addition, that would have a significant impact on interactive C++ where header inclusion essentially becomes a no-op and entities will be only parsed on demand.

The Cling interpreter implements a very naive but efficient cross-translation unit lazy compilation optimization which scales across hundreds of libraries in the field of high-energy physics.

// 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;
    

Expected result:

• Design and implementation of on-demand compilation for non-templated functions
• Support non-templated structs and classes
• Run performance benchmarks on relevant codebases and prepare report
• Prepare a community RFC document
• [Stretch goal] Support templates

Further reading
[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

Skills: Knowledge of C++, Deeper understanding of how Clang works, knowledge of Clang AST and Preprocessor.

Project size:Large

Difficulty: Hard

Confirmed Mentor: Vassil Vassilev, Matheus Izvekov

Discourse: URL

Description of the project: Clang-Doc is a C/C++ documentation generation tool created as an alternative for Doxygen and built on top of LibTooling. This effort started in 2018 and critical mass has landed in 2019, but the development has been largely dormant since then, mostly due to a lack of resources.

The tool can currently generate documentation in Markdown and HTML formats, but the tool has some structural issues, is difficult to use, the generated documentation has usability issues and is missing several key features:

• Not all C/C++ constructs are currently handled by the Markdown and HTML emitter limiting the tool’s usability.
• The generated HTML output does not scale with the size of the codebase making it unusable for larger C/C++ projects.
• The implementation does not always use the most efficient or appropriate data structures which leads to correctness and performance issues.
• There is a lot of duplicated boiler plate code which could be improved with templates and helpers.

Expected result: The goal of this project is to address the existing shortcomings and improve the usability of Clang-Doc to the point where it can be used to generate documentation for large scale projects such as LLVM. The ideal outcome is that the LLVM project will use Clang-Doc for generating its reference documentation.

Successful proposals should focus not only on addressing the existing limitations, but also draw inspiration for other potential improvements from other similar tools such as hdoc, standardese, subdoc or cppdocgen.

Skills: Experience with web technologies (HTML, CSS, JS) and an intermediate knowledge of C++. Previous experience with Clang/LibTooling is a bonus but not required.

Project size: Either medium or large.

Difficulty: Medium

Confirmed Mentor: Petr Hosek, Paul Kirth

Discourse: URL

Description

Use the variable location information from the debug info to annotate LLDB’s disassembler (and `register read`) output with the location and lifetime of source variables. The rich disassembler output should be exposed as structured data and made available through LLDB’s scripting API so more tooling could be built on top of this. In a terminal, LLDB should render the annotations as text.

Expected outcomes

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

using the debug information that LLDB also has access to (observe how the source variable i is in r15 from [0x100000f77+slide))

$ 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

The goal would be to produce output like this for a subset of unambiguous cases, for example, variables that are constant or fully in registers.

Confirmed mentors and their contacts

• Adrian Prantl aprantl@apple.com (primary contact)
• Jonas Devlieghere jdevlieghere@apple.com

Required / desired skills

Required:

• Good understanding of C++
• Familiarity with using a debugger on the terminal
• Need to be familiar with all the concepts mentioned in the example above
• Need to have a good understanding of at least one assembler dialect for machine code (x86_64 or AArch64).

Desired:

• Compiler knowledge including data flow and control flow analysis is a plus.
• Being able to navigate debug information (DWARF) is a plus.

Size of the project.

medium (~175h)

An easy, medium or hard rating if possible

hard

Discourse: URL

Description

LLVM-reduce, and similar tools perform delta debugging but are less useful if many implicit constraints exist and violation could easily lead to errors similar to the cause that is to be isolated. This project is about developing a GPU-aware version, especially for execution time bugs, that can be used in conjunction with LLVM/OpenMP GPU-record-and-replay, or simply a GPU loader script, to minimize GPU test cases more efficiently and effectively.

Expected outcomes

A tool to reduce GPU errors without loosing the original error. Optionally, other properties could be the focus of the reduction, not only errors.

Confirmed mentors and their contacts

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

Required / desired skills

Required:

• Good understanding of C++
• Familiarity with GPUs and LLVM-IR

Desired:

• Compiler knowledge including data flow and control flow analysis is a plus.
• Experience with debugging and bug reduction techniques (llvm-reduce) is helpful

Size of the project.

medium

An easy, medium or hard rating if possible

medium

Discourse: URL

Description

Modern C++ defines parallel algorithms as part of the standard library, like `std::transform_reduce(std::execution::par_unseq, vec.begin(), vec.end(), 0, std::plus, …)`. In this project we want to extend an implementation of those that is using OpenMP, including GPU offload, where reasonable. While some algorithms might be amenable to GPU offload via a pure (wrapper) runtime solution, we know others, especially those featuring user provided functors, will also require static program analysis and potentially transformation for additional data management. The goal of the project is to explore different algorithms and the options we have to execute them on the host as well as on accelerator devices, esp. GPUs, automatically via OpenMP.

Expected outcomes

Improvements to the prototype support of offloading in libcxx. Evaluations against other offloading approaches and documentation on the missing parts and shortcommings.

Confirmed mentors and their contacts

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

Required / desired skills

Required:

• Good understanding of C++ and C++ standard algorithms
• Familiarity with GPUs and (OpenMP) offloading

Desired:

• Experience with libcxx (development).
• Experience debugging and profiling GPU code.

Size of the project.

large

An easy, medium or hard rating if possible

medium

Discourse: URL

Description

LLVM has lots of thresholds and flags to avoid "costly cases". However, it is unclear if these thresholds are useful, their value is reasonable, and what impact they really have. Since there are a lot, we cannot do a simple exhaustive search. In some prototype work we introduced a C++ class that can replace hardcoded values and offers control over the threshold, e.g., you can increase the recursion limit via a command line flag from the hardcoded "6" to a different number. In this project we want to explore the thresholds, when they are hit, what it means if they are hit, how we should select their values, and if we need different "profiles".

Expected outcomes

Statistical evidence on the impact of various thresholds inside of LLVM's code base, including compile time changes, impact on transformations, and performance measurements.

Confirmed mentors and their contacts

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

Required / desired skills

Required:

• Profiling skills and knowledge of statistical reasoning

Desired:

• Good understanding of the LLVM code base and optimization flow

Size of the project.

medium

An easy, medium or hard rating if possible

easy

Discourse: URL

Description

We have begun work on a libc library targeting GPUs. This will allow users to call functions such as malloc or memcpy while executing on the GPU. However, it is important that these implementations be functional and performant. The goal of this project is to benchmark the implementations of certain libc functions on the GPU. Work would include writing benchmarks to test the current implementations as well as writing more optimal implementations.

Expected outcomes

In-depth performance for libc functions. Overhead of GPU-to-CPU remote procedure calls. More optimal implementations of 'libc' functions.

Confirmed mentors and their contacts

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

Required / desired skills

Required:

• Profiling skills and understanding of GPU architecture

Desired:

• Experience with libc utilities

Size of the project.

small

An easy, medium or hard rating if possible

easy

Discourse: URL

Description

GPU First is a methodology and framework that can enable any existing host code to execute the entire program on a GPU without any modification from users. The goal of this project is two folded: 1) Port host code to handle RPC to the new plugin and rewrite it with the host RPC framework introduced in the GPU LibC project. 2) Explore the support for MPI among multiple thread blocks on a single GPU, or even multiple GPUs.

Expected outcomes

More efficient GPU First framework that can support both NVIDIA and AMD GPUs. Optionally, upstream the framework.

Confirmed mentors and their contacts

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

Required / desired skills

Required:

• Good understanding of C++ and GPU architecture
• Familiarity with GPUs and LLVM IR

Desired:

• Good understanding of the LLVM code base and OpenMP target offloading

Size of the project.

medium

An easy, medium or hard rating if possible

medium

Discourse: URL

Description: Heterogeneous programming models such as SYCL, OpenMP and OpenACC help developers to offload computationally intensive kernels to GPUs and other accelerators. MLIR is expected to unlock new high-level optimisations and better code generation for the next generation of compilers for heterogeneous programming models. However, the availability of a robust MLIR-emitting C/C++ frontend is a prerequisite for these efforts.

The ClangIR (CIR) project aims to establish a new intermediate representation (IR) for Clang. Built on top of MLIR, it provides a dialect for C/C++ based languages in Clang, and the necessary infrastructure to emit it from the Clang AST, as well as a lowering path to the LLVM-IR dialect. Over the last year, ClangIR has evolved into a mature incubator project, and a recent RFC on upstreaming it into the LLVM monorepo has seen positive comments and community support.

The overall goal of this GSoC project is to identify and implement missing features in ClangIR to make it possible to compile GPU kernels in the OpenCL C language to LLVM-IR for the SPIR-V target. The OpenCL to SPIR-V flow is a great environment for this project because a) it is already supported in Clang and b) OpenCL's work-item- and work-group-based programming model still captures modern GPU architectures well. The contributor will extend the AST visitors, the dialect and the LLVM-IR lowering, to add support e.g. for multiple address spaces, vector and custom floating point types, and the spir_kernel and spir_func calling conventions.

A good starting point for this work is the Polybench-GPU benchmark suite. It contains self-contained small- to medium sized OpenCL implementations of common algorithms. We expect only the device code (*.cl files) to be compiled via ClangIR. The existing OpenCL support in Clang can be used to create lit tests with reference LLVM-IR output to guide the development. Optionally, the built-in result verification and time measurements in Polybench could also be used to assess the correctness and quality of the generated code.

Expected result: Polybench-GPU's 2DCONV, GEMM and CORR OpenCL kernels can be compiled with ClangIR to LLVM-IR for SPIR-V.

Skills: Intermediate C++ programming skills and familiarity with basic compiler design concepts are required. Prior experience with LLVM IR, MLIR, Clang or GPU programming is a big plus, but willingness to learn is also a possibility.

Project size: Large

Difficulty: Medium

Confirmed Mentors: Julian Oppermann, Victor Lomüller, Bruno Cardoso Lopes

Discourse: URL

Description:

Half precision is an IEEE 754 floating point format that has been widely used recently, especially in machine learning and AI. It has been standardized as _Float16 in the latest C23 standard, bringing its support to the same level as float or double data types. The goal for this project is to implement C23 half precision math functions in the LLVM libc library.

Expected result:

• Setup the generated headers properly so that the type and the functions can be used with various compilers (+versions) and architectures.
• Implement generic basic math operations supporting half precision data types that work on supported architectures: x86_64, arm (32 + 64), risc-v (32 + 64), and GPUs.
• Implement specializations using compiler builtins or special hardware instructions to improve their performance whenever possible.
• If time permits, we can start investigating higher math functions for half precision.

Skills:

Intermediate C++ programming skills and familiarity with basic compiler design concepts are required. Prior experience with LLVM IR, MLIR, Clang or GPU programming is a big plus, but willingness to learn is also a possibility.

Project size: Large

Difficulty: Easy/Medium

Confirmed Mentors: Tue Ly, Joseph Huber,

Discourse: URL

Google Summer of Code 2023 was very successful for LLVM project. For the list of accepted and completed projects, please take a look into Google Summer of Code website.

Description of the project: In Just-In-Time compilers we often choose a low optimization level to minimize compile time and improve launch times and latencies, however some functions (which we call hot functions) are used very frequently and for these functions it is worth optimizing more heavily. In general hot functions can only be identified at runtime (different inputs will cause different functions to become hot), so the aim of the reoptimization project is to build infrastructure to (1) detect hot functions at runtime and (2) compile them a second time at a higher optimization level, hence the name "re-optimization".

There are many possible approaches to both parts of this problem. E.g. hot functions could be identified by sampling, or using existing profiling infrastructure, or by implementing custom instrumentation. Reoptimization could be applied to whole functions, or outlining could be used to enable optimization of portions of functions. Re-entry into the JIT infrastructure from JIT’d code might be implemented on top of existing lazy compilation, or via a custom path.

Whatever design is adopted, the goal is that the infrastructure should be generic so that it can be used by other LLVM API clients, and should support out-of-process JIT-compilation (so some of the solution will be implemented in the ORC runtime).

Expected result:

• Improve ergonomics of indirection – ideally all forms of indirection (for re-optimization, lazy compilation, and procedure-linkage-tables) should be able to share a single stub (and/or binary rewriting metadata) at runtime.
• Implement basic re-optimization on top of the tidied up indirection.
• (Stretch goal) Garbage-collect unoptimized code that is no longer needed once the optimized version is available.

Desirable skills: Intermediate C++; Understanding of LLVM and the LLVM JIT in particular.

Project size: Large.

Difficulty: Medium

Confirmed Mentor: Vassil Vassilev, Lang Hames

Discourse: URL

Description of the project: JITLink is LLVM's new JIT linker API -- the low-level API that transforms compiler output (relocatable object files) into ready-to-execute bytes in memory. To do this JITLink’s generic linker algorithm needs to be specialized to support the target object format (COFF, ELF, MachO), and architecture (arm, arm64, i386, x86-64). LLVM already has mature implementations of JITLink for MachO/arm64, MachO/x86-64, ELF/x86-64, ELF/aarch64 and COFF/x86-64, while the implementations for ELF/riscv, ELF/aarch32 and COFF/i386 are still relatively new.
You can either work on an entirely new architecture like PowerPC or eBPF, or complete one of the recently added JITLink implementations. In both cases you will likely reuse the existing generic code for one of the target object formats. You will also work on relocation resolution, populate PLTs and GOTs and wire up the ORC runtime for your chosen target.

Expected result: Write a JITLink specialization for a not-yet-supported or incomplete format/architecture such as PowerPC, AArch32 or eBPF.

Desirable skills: Intermediate C++; Understanding of LLVM and the LLVM JIT in particular; familiarity with your chosen format/architecture, and basic linker concepts (e.g. sections, symbols, and relocations).

Project size: Large.

Difficulty:Medium

Confirmed Mentor: Vassil Vassilev, Lang Hames

Discourse: URL

Description of the project: While the primary job of a compiler is to produce fast code (good run-time performance), it is also important that optimization doesn’t take too much time (good compile-time performance). The goal of this project is to improve compile-time without hurting optimization quality.
The general approach to this project is:

1. Pick a workload to optimize. For example, this could be a file from CTMark compiled in a certain build configuration (e.g. -O0 -g or -O3 -flto=thin).
2. Collect profiling information. This could involve compiler options like -ftime-report or -ftime-trace for a high-level overview, as well as perf record or valgrind --tool=callgrind for a detailed profile.
3. Identify places that are unexpectedly slow. This is heavily workload dependent.
4. Try to optimize an identified hotspot, ideally without impacting generated code. The compile-time tracker can be used to quickly evaluate impact on CTMark.

Expected result: Substantial improvements on some individual files (multiple percent), and a small improvement on overall geomean compile-time.

Desirable skills: Intermediate C++. Familiarity with profiling tools (especially if you are not on Linux, in which case I won’t be able to help).

Project size: Either medium or large.

Difficulty: Medium

Confirmed Mentor: Nikita Popov

Discourse: URL

Description of the project: The Rust programming language uses LLVM for code generation, and heavily relies on LLVM’s optimization capabilities. However, there are many cases where LLVM fails to optimize typical code patterns that are emitted by rustc. Such issues are reported using the I-slow and/or A-LLVM labels.
The usual approach to fixing these issues is:

1. Inspect the --emit=llvm-ir output on Godbolt.
2. Create an LLVM IR test case that is not optimized when run through opt -O3.
3. Identify a minimal missing transform and prove its correctness using alive2.
4. Identify which LLVM pass or passes could perform the transform.
5. Add necessary test coverage and implement the transform.
6. (Much later: Check that the issue is really resolved after the next major LLVM version upgrade in Rust.)

Expected result: Fixes for a number of easy to medium Rust optimization failures. Preliminary analysis for some failures even if no fix was implemented.

Desirable skills: Intermediate C++ for implementation. Some familiarity with LLVM (at least ability to understand LLVM IR) for analysis. Basic Rust knowledge (enough to read, but not write Rust).

Project size: Either medium or large.

Difficulty: Medium

Confirmed Mentor: Nikita Popov

Discourse: URL

Description of the project: The Clang compiler is part of the LLVM compiler infrastructure and supports various languages such as C, C++, ObjC and ObjC++. The design of LLVM and Clang enables them to be used as libraries, and has led to the creation of an entire compiler-assisted ecosystem of tools. The relatively friendly codebase of Clang and advancements in the JIT infrastructure in LLVM further enable research into different methods for processing C++ by blurring the boundary between compile time and runtime. Challenges include incremental compilation and fitting compile/link time optimizations into a more dynamic environment.

Incremental compilation pipelines process code chunk-by-chunk by building an ever-growing translation unit. Code is then lowered into the LLVM IR and subsequently run by the LLVM JIT. Such a pipeline allows creation of efficient interpreters. The interpreter enables interactive exploration and makes the C++ language more user friendly. The incremental compilation mode is used by the interactive C++ interpreter, Cling, initially developed to enable interactive high-energy physics analysis in a C++ environment.

Our group puts efforts to incorporate and possibly redesign parts of Cling in Clang mainline through a new tool, clang-repl. The project aims at the design and implementation of robust autocompletion when users type C++ at the prompt of clang-repl. For example:

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

Expected result: There are several foreseen tasks:

• Research the current approaches for autocompletion in clang such as clang -code-completion-at=file:col1:col2.
• Implement a version of the autocompletion support using the partial translation unit infrastructure in clang’s libInterpreter.
• Investigate the requirements for semantic autocompletion which takes into account the exact grammar position and semantics of the code. Eg:

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

• Present the work at the relevant meetings and conferences.

Project size:Large.

Difficulty: Medium

Confirmed Mentor: Vassil Vassilev

Discourse: URL

Description of the project: Clang currently handles modules independently in each clang instance using the filesystem for synchronization of which instance builds a given module. This has many issues with soundness and performance due to tradeoffs made for module reuse and filesystem contention.

Clang has another way of building modules, explicitly built modules, that currently requires build system changes to adopt. Here the build system determines which modules are needed, for example by using clang-scan-deps, and ensures those modules are built before running the clang compile task that needs them.

In order to allow adoption of this new way of building modules without major build system work we need a module build daemon. With a small change to the command line, clang will connect to this daemon and ask for the modules it needs. The module build daemon then either returns an existing valid module, or builds and then returns it.

There is an existing open source dependency scanning daemon that is in a llvm-project fork. This only handles file dependencies, but has an IPC mechanism. This IPC system could be used as a base for the modules build daemon, but does need to be extended to work on Windows.

Expected result: A normal project using Clang modules with an existing build system (like Make or CMake) can be built using only explicitly built modules via a modules build daemon.

Desirable skills: Intermediate C++ programming skills; familiarity with compilers; familiarity with Clang is an asset, but not required.

Project size: 175h or 350h depending on reuse of IPC

Difficulty: medium

Confirmed Mentors: Michael Spencer, Jan Svoboda

Discourse: URL

Description of the project: Swift-DocC is the canonical documentation compiler for the Swift OSS project. However Swift-DocC is not Swift specific and uses SymbolKit's languaguage agnostic JSON-based symbol graph format to understand which symbols are available in the code, this way any language can be supported by Swift-DocC as long as there is a symbol graph generator.

Clang supports symbol graph generation for C and Objective-C as described in [RFC] clang support for API information generation in JSON. Today, support for Objective-C categories is not complete, on one hand if the category extends a type in the current module, the category members are assumed to belong to the extended type itself. On the other hand, if the extended type belongs to another module the category is ignored. Nonetheless, it is common to extend types belonging to other modules in Objective-C as part of the public API of the module. The goal of this project is to extend the symbol graph format to accommodate Objective-C categories and to implement support for generating this information both through clang and through libclang.

Expected result: Adding the necessary support to clang's symbol graph generator and in libclang for describing categories of symbols defined in other modules. This might involve additions to SymbolKit that would need to be discussed with that community.

Desirable skills: Intermediate C++ programming skills; familiarity with clang and Objective-C are assets but not required.

Project size: Medium

Difficulty: Medium

Confirmed Mentors: Daniel Grumberg, Zixu Wang, Juergen Ributzka

Discourse: URL

Description of the project: Swift-DocC is the canonical documentation compiler for the Swift OSS project. However Swift-DocC is not Swift specific and uses SymbolKit's languaguage agnostic JSON-based symbol graph format to understand which symbols are available in the code, this way any language can be supported by Swift-DocC as long as there is a symbol graph generator.

Clang supports symbol graph generation for C and Objective-C as described in [RFC] clang support for API information generation in JSON.

Currently the emitted symbol graph format does not support various C++ constructs such as templates and exceptions and the symbol graph generator does not fully understand C++. This project aims to introduce support for various C++ constructs in the symbol graph format and to implement support for generating this data in clang.

Expected result: Adding the necessary support to clang's symbol graph generator and in libclang for describing categories of symbols defined in other modules. This will involve additions to SymbolKit that would need to be discussed with that community.

Desirable skills: Intermediate C++ programming skills; familiarity with clang and Objective-C are assets but not required.

Project size: Large

Difficulty: Medium/Hard

Confirmed Mentors: Daniel Grumberg, Zixu Wang, Juergen Ributzka

Discourse: URL

Description of the project: Swift-DocC is the canonical documentation compiler for the Swift OSS project. However Swift-DocC is not Swift specific and uses SymbolKit's languaguage agnostic JSON-based symbol graph format to understand which symbols are available in the code, this way any language can be supported by Swift-DocC as long as there is a symbol graph generator.

Clang supports symbol graph generation for C and Objective-C as described in [RFC] clang support for API information generation in JSON.

Currently users can use clang to generate symbol graph files using the clang -extract-api command line interface or generating symbol graphs for a specific symbol using the libclang interface. This project would entail adding a third mode that would generate the symbol graph output as a side-effect of a regular compilation job. This can enable using the symbol graph format as a light weight alternative to clang Index or clangd for code intelligence services.

Expected result: Enable generating symbol graph files during a regular compilation (or module build); provide a tool to merge symbol graph files in the same way a static linker links individual object files; Extend clang Index to support all the information contained by symbol graph files.

Desirable skills: Intermediate C++ programming skills; familiarity with clang and Objective-C are assets but not required.

Project size: Medium

Difficulty: Medium/Hard

Confirmed Mentors: Daniel Grumberg, Zixu Wang, Juergen Ributzka

Discourse: URL

Description: The diagnostics clang emits are ultimately its interface to the developer. While the diagnostics are generally good, there are some rough edges that need to be ironed out. Some cases can be improved by special-casing them in the compiler as well.

As one can see from Clang’s issue tracker, there are lots of issues open against clang’s diagnostics.

This project does not aim to implement one big feature but instead focuses on smaller, incremental improvements to Clang’s diagnostics.

Possible example issues to resolve:

• Calling nullptr function pointer in a constexpr function results in poor diagnostic
• Print name of uninitialized subobject (instead of type)
• https://github.com/llvm/llvm-project/issues/57906
• clang(++) unhelpful frame-larger-than warning, very small stack frame exceeding very large limit
• Any other diagnostics issue you find interesting or ran into personally.

Expected outcomes: At least three fixed smaller diagnostics issues, or one larger implemented diagnostics improvement.

Confirmed Mentor:Timm Bäder

Desirable skills:

• Intermediate C++ knowledge.
• Preferably experience in the Clang code base, since the issues mentioned can have their root cause in various parts of it.
• Preferably an already working local LLVM build

Project type: Medium/200 hr

Discourse URL

Description: The Clang compiler is part of the LLVM compiler infrastructure and supports various languages such as C, C++, ObjC and ObjC++. The design of LLVM and Clang enables them to be used as libraries, and has led to the creation of an entire compiler-assisted ecosystem of tools. The relatively friendly codebase of Clang and advancements in the JIT infrastructure in LLVM further enable research into different methods for processing C++ by blurring the boundary between compile time and runtime. Challenges include incremental compilation and fitting compile/link time optimizations into a more dynamic environment.

Incremental compilation pipelines process code chunk-by-chunk by building an ever-growing translation unit. Code is then lowered into the LLVM IR and subsequently run by the LLVM JIT. Such a pipeline allows creation of efficient interpreters. The interpreter enables interactive exploration and makes the C++ language more user friendly. The incremental compilation mode is used by the interactive C++ interpreter, Cling, initially developed to enable interactive high-energy physics analysis in a C++ environment.

We invest efforts to incorporate and possibly redesign parts of Cling in Clang mainline through a new tool, clang-repl. The project aims implementing tutorials demonstrating the capabilities of the project and investigating adoption of clang-repl in xeus-clang-repl prototype allowing to write C++ in Jupyter.

Expected result: There are several foreseen tasks:

• Write several tutorials demostrating the current capabilities of clang-repl.
• Investigate the requirements for adding clang-repl as a backend to xeus-cling.
• Improve the xeus kernel protocol for clang-repl.
• Prepare a blog post about clang-repl and possibly Jupyter. Present the work at the relevant meetings and conferences.

Confirmed Mentor: Vassil Vassilev David Lange

Desirable skills: Intermediate C++; Understanding of Clang and the Clang API in particular

Project type: Medium

Discourse URL

Description: The Clang compiler is part of the LLVM compiler infrastructure and supports various languages such as C, C++, ObjC and ObjC++. The design of LLVM and Clang enables them to be used as libraries, and has led to the creation of an entire compiler-assisted ecosystem of tools. The relatively friendly codebase of Clang and advancements in the JIT infrastructure in LLVM further enable research into different methods for processing C++ by blurring the boundary between compile time and runtime. Challenges include incremental compilation and fitting compile/link time optimizations into a more dynamic environment.

Incremental compilation pipelines process code chunk-by-chunk by building an ever-growing translation unit. Code is then lowered into the LLVM IR and subsequently run by the LLVM JIT. Such a pipeline allows creation of efficient interpreters. The interpreter enables interactive exploration and makes the C++ language more user friendly. The incremental compilation mode is used by the interactive C++ in Jupyter via the xeus kernel protocol. Newer versions of the protocol allow possible in-browser execution allowing further possibilities for clang-repl and Jupyter.

We invest efforts to incorporate and possibly redesign parts of Cling in Clang mainline through a new tool, clang-repl. The project aims to add WebAssembly support in clang-repl and adopt it in xeus-clang-repl to aid Jupyter-based C++.

Expected result: There are several foreseen tasks:

• Investigate feasibility of generating WebAssembly in a similar way to the new interactive CUDA support.
• Enable generating WebAssembly in clang-repl.
• Adopt the feature in xeus-clang-repl.
• Prepare a blog post about clang-repl and possibly Jupyter. Present the work at the relevant meetings and conferences.

Confirmed Mentor: Vassil Vassilev Alexander Penev

Desirable skills: Good C++; Understanding of Clang and the Clang API and the LLVM JIT in particular

Project type: Large

Discourse URL

Description of the project GNU toolchain is used widely for building embedded targets. There's a certain momentum in the Clang/LLVM community towards improving the Clang toolchain to support embedded targets. Using the Clang toolchain as an alternative can help us improve code quality, find and fix security bugs, improve developer experience and take advantage of the new ideas and the momentum surrounding the Clang/LLVM community in supporting embedded devices.

A non-comprehensive list of improvements that can be made to LLD:

• --print-memory-usage support

  "--print-memory-usage" in GCC provides a breakdown of the memory used in each memory region defined in the linker file. Embedded developers use this flag to understand the impact on memory. Often embedded systems define multiple memory regions with different space constraints. Supporting this in Clang toolchain will help projects that wish to use Clang toolchain for their projects.

• Linkmap

  Currently, the LLD linker's linkmap output is not as rich as the BFD linker output. Achieving feature parity on linkmap output will be highly useful in analyzing the binaries created by the LLD linker. Further, outputting linkmap in different formats (current LLD output, BFD, and JSON) can help build automation tools for investigating the artifacts produced by the linker.

• --print-gc-sections improvement

  When the "--print-gc-sections" flag is enabled, LLD prints the sections that were discarded during the linking process. This information currently does not include the mapping between the symbol and the section groups, which is useful for debugging. Preserving this information during the linking process will require modifications to internal linker data structures.

Project size: Medium or Large

Difficulty: Medium/Hard

Skills: C++

Expected result:

• Implementation of "--print-memory-usage" flag.
• Support for new linkmap output formats 1. BFD and 2. JSON.
• Improved "--print-gc-sections" output to include information about the surviving symbols.

Confirmed Mentors: Prabhu Rajasekaran Petr Hosek

Discourse: URL

Description: MLIR’s Presburger Library, FPL (https://grosser.science/FPL), provides mathematical abstractions for polyhedral compilation and analysis. The main abstraction that the library provides is a set of integer tuples defined by a system of affine inequality constraints. The library supports standard set operations over such sets. The result will be a set defined by another constraint system, possibly having more constraints. When many set operations are performed in sequence, the constraint system may become very large, negatively impacting performance. There are several potential ways to simplify the constraint system; however, this involves performing additional computations. Thus, spending more time on more aggressive simplifications may make each individual operation slower, but at the same time, insufficient simplifications can make sequences of operations slow due to an explosion in constraint system size. The aim of this project is to find the right balance between the two.

The goals of this project:

• Understand the library's performance in terms of runtime and output size.
• Optimize the library by finding the best output size and performance tradeoff.

Expected outcomes:

• Benchmarking the performance and output constraint complexity of the primary operations of the library.
• Implementing simplification heuristics.
• A better understanding of which simplification heuristics improve overall performance enough to be worth the additional computational cost.

Desirable skills: Intermediate C++, Experience in benchmarking

Project size: Large

Difficulty: Medium

Confirmed mentors: Kunwar Grover

Discourse: URL

Description: The project aims to develop an interactive query language for MLIR that enables developers to query the MLIR IR dynamically. The tool will provide a REPL (or command-line) interface to enable users to query various properties of MLIR code, such as "isConstant" and "resultOf". The proposed tool is intended to be similar to clang-query, which allows developers to match AST expressions in C++ code using a TUI with autocomplete and other features.

The goals of this project:

• Understand the MLIR IR representation and common explorations user do.
• Implement a REPL to execute queries over MLIR IR.

Expected outcomes:

• Standalone that can be used to interactively explore IR.
• Implement common matchers that are usable by the tool.
• (stretch) Enable extracting parts of the IR matched by query into self-contained IR snippets.

Desirable skills: Intermediate C++, Experience in writing/debugging peephole optimizations

Project size: Either medium or large.

Difficulty: Medium

Confirmed mentors: Jacques Pienaar

Discourse: URL

Description of the project We are using machine-guided compiler optimizations ("MLGO") for register allocation eviction and inlining for size, in real-life deployments. The ML models have been trained with reinforcement learning algorithms. Expanding to more performance areas is currently impeded by the poor prediction quality of our performance estimation models. Improving those is critical to the effectiveness of reinforcement learning training algorithms, and therefore to enabling applying MLGO systematically to more optimizations.

Project size: either 175 or 350 hr.

Difficulty: Medium

Skills: C/C++, some compiler experience, some Python. ML experience is a bonus.

Expected outcomes: Better modeling of the execution environment by including additional runtime/profiling information, such as additional PMU data, LLC miss probabilities or branch mispredictions. This involves (1) building a data collection pipeline that covers additional runtime information, (2) modifying the ML models to allow processing this data, and (3) modifying the training and inference process for the models to make use this data.

Today, the models are almost pure static analysis; they see the instructions, but they make one-size-fits-all assumptions about the execution environment and the runtime behavior of the code. The goal of this project is to move from static analysis towards more dynamic models that better represent code the way it actually executes.

Mentors Ondrej Sykora, Mircea Trofin, Aiden Grossman

Discourse URL

Description of the project: The Clang static analyzer comes with an experimental implementation of taint analysis, a security-oriented analysis technique built to warn the user about flow of attacker-controlled ("tainted") data into sensitive functions that may behave in unexpected and dangerous ways if the attacker is able to forge the right input. The programmer can address such warnings by properly "sanitizing" the tainted data in order to eliminate these dangerous inputs. A common example of a problem that can be caught this way is SQL injections. A much simpler example, which is arguably much more relevant to users of Clang, is buffer overflow vulnerabilities caused by attacker-controlled numbers used as loop bounds while iterating over stack or heap arrays, or passed as arguments to low-level buffer manipulating functions such as memcpy().

Being a static symbolic execution engine, the static analyzer implements taint analysis by simply maintaining a list of "symbols" (named unknown numeric values) that were obtained from known taint sources during the symbolic simulation. Such symbols are then treated as potentially taking arbitrary concrete values, as opposed to the general case of taking an unknown subset of possible values. For example, division by a unchecked unknown value doesn't necessarily warrant a division by zero warning, because it's typically not known whether the value can be zero or not. However, division by an unchecked tainted value does immediately warrant a division by zero warning, because the attacker is free to pass zero as an input. Therefore the static analyzer's taint infrastructure consists of several parts: there is a mechanism for keeping track of tainted symbols in the symbolic program state, there is a way to define new sources of taint, and a few path-sensitive checks were taught to consume taint information to emit additional warnings (like the division by zero checker), acting as taint "sinks" and defining checker-specific "sanitization" conditions.

The entire facility is flagged as experimental: it's basically a proof-of-concept implementation. It's likely that it can be made to work really well, but it needs to go through some quality control by running it on real-world source code, and a number of bugs need to be addressed, especially in individual checks, before we can declare it stable. Additionally, the tastiest check of them all – buffer overflow detection based on tainted loop bounds or size parameters – was never implemented. There is also a related check for array access with tainted index – which is, again, experimental; let's see if we can declare this one stable as well!

Expected result: A number of taint-related checks either enabled by default for all users of the static analyzer, or available as opt-in for users who care about security. They're confirmed to have low false positive rate on real-world code. Hopefully, the buffer overflow check is one of them.

Desirable skills: Intermediate C++ to be able to understand LLVM code. We'll run our analysis on some plain C code as well. Some background in compilers or security is welcome but not strictly necessary.

Project size: Either medium or large.

Difficulty: Medium

Confirmed Mentors: Artem Dergachev, Gábor Horváth, Ziqing Luo

Discourse: URL

Description of the project This continues the work of GSoC 2020 and 2021. Developers generally use standard optimization pipelines like -O2 and -O3 to optimize their code. Manually crafted heuristics are used to determine which optimization passes to select and how to order the execution of those passes. However, this process is not tailored for a particular program, or kind of program, as it is designed to perform “reasonably well” for any input. We want to improve the existing heuristics or replace the heuristics with machine learning-based models so that the LLVM compiler can provide a superior order of the passes customized per program. The last milestone enabled feature extraction, and started investigating training a policy for selecting a more appropriate pass pipeline.

Project size: either 175 or 350 hr.

Difficulty: Medium

Skills: C/C++, some compiler experience. ML experience is a bonus.

Expected outcomes: Pre-trained model selecting the most economical optimization pipeline, with no loss in performance; hook-up of model in LLVM; (re-)training tool; come up with new optimization sequences through search or learning.

Mentors Tarindu Jayatilaka, Mircea Trofin, Johannes Doerfert

Discourse URL

Description of the project:
Clang supports source-based coverage that shows which lines of code are covered by the executed tests [1]. It uses llvm-profdata [2] and llvm-cov [3] tools to generate coverage reports. llvm-cov currently generates a single top-level index HTML file. For example, a single top-level directory code coverage report [4] for LLVM repo is published on a coverage bot. Top-level indexing causes rendering scalability issues in large projects, such as Fuchsia [5]. The goal of this project is to generate a hierarchical directory structure in generated coverage html reports to match the directory structure and solve scalability issues. Chromium uses its own post-processing tools to show a per-directory hierarchical structure for coverage results [6]. Similarly, Lcov, which is a graphical front-end Gcov[7], provides a one-level directory structure to display coverage results [8].
[1] Source-based code coverage
[2] llvm-profdata
[3] llvm-cov
[4] LLVM coverage reports
[5] Fuchsia
[6] Coverage summary for Chromium
[7] Gcov
[8] Lcov coverage reports
[9] Issue #54711: Support per-directory index files for HTML coverage report

Expected result: Implement a support in hierarchical directory structure in generated coverage html reports and show the usage of this feature in LLVM repo code coverage reports.

Project size: Medium or Large

Difficulty: Medium

Confirmed Mentors: Gulfem Savrun Yeniceri Petr Hosek

Discourse: URL

Description of the project Developers often use compiler generated remarks and analysis reports to optimize their code. While compilers in general are good at including source code positions (i.e line and column numbers) in the generated messages, it is useful if these generated messages also include the corresponding source-level expressions. The approach used by the LLVM implementation is to use a small set of intrinsic functions to define a mapping between LLVM program objects and the source-level expressions. The goal of this project is to use the information included within these intrinsic functions to either generate the source expression corresponding to LLVM values or to propose and implement solutions to get the same if the existing information is insufficient. Optimizing memory accesses in a program is important for application performance. We specifically intend to use compiler analysis messages that report source-level memory accesses corresponding to the LLVM load/store instructions that inhibit compiler optimizations. As an example, we can use this information to report memory access dependences that inhibit vectorization.

Project size: Medium

Difficulty: Medium

Skills: Intermediate C++, familiarity with LLVM core or willingness to learn the same.

Expected result: Provide an interface which takes an LLVM value and returns a string corresponding to the equivalent source-level expression. We are especially interested in using this interface to map addresses used in load/store instructions to equivalent source-level memory references.

Confirmed Mentors: Satish Guggilla (satish.guggilla@intel.com) Karthik Senthil (karthik.senthil@intel.com)

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