LLVM Compiler Infrastructure — Project Ideas

The LLVM Compiler Infrastructure

Site Map: Download! Search this Site Useful Links Release Emails Maintained by the | Open LLVM Projects

• Google Summer of Code Ideas & Projects

Google Summer of Code 2026 - Google Summer of Code 2025LLVM CoreClangLLDBLLVM libcClangIRClang Static AnalyzerEnzyme(FormerOffload)OpenMP Offloading

Google Summer of Code 2024LLVM CoreClangLLDB**(OpenMP) OffloadClangIRLLVM libc**

Google Summer of Code 2023- LLVM Core ClangOut-of-process execution for clang-replImprove and Stabilize the Clang Static Analyzer's "Taint Analysis" ChecksImplement autocompletion in clang-replModules build daemon: build system agnostic support for explicitly built modulesExtractAPI Objective-C categoriesExtractAPI C++ SupportExtractAPI while buildingImprove Clang diagnosticsTutorial development with clang-replAdd WebAssembly Support in clang-repl

LLD - MLIR - Code Coverage - ClangIR - Enzyme

Google Summer of Code 2022- LLVM CoreImplement a shared-memory based JITLinkMemoryManager for out-of-process JITtingModernize the LLVM "Building A JIT" tutorial seriesWrite JITLink support for a new format/architectureInstrumentation of Clang/LLVM for Compile TimeRicher symbol dependency information for LTOMachine Learning Guided Ordering of Compiler Optimization PassesLearning Loop Transformation HeuristicsEvaluate and Expand the Module-Level InlinerRemove undef: move uninitialized memory to poisonAdd ABI/API export annotations to the LLVM build Clang- Polly - Enzyme

Google Summer of Code 2021- LLVM CoreDistributed lit testingLearning Loop Transformation HeuristicsFuzzing LLVM-IR Passesllvm.assumethe missing piecesImplement a shared-memory based JITLinkMemoryManager for out-of-process JITtingModernize the LLVM "Building A JIT" tutorial seriesWrite JITLink support for a new format/architectureFix fundamental issues in LLVM's IRUtilize LoopNest Pass Clang- OpenMP - OpenACC - Polly - Enzyme - Clang Static Analyzer - LLDB

Google Summer of Code 2020- LLVM CoreImprove debugging of optimized codeImprove inter-procedural analyses and optimizationsImprove parallelism-aware analyses and optimizationsMake LLVM passes debug info invariantImprove MergeFunctions to incorporate MergeSimilarFunction patches and ThinLTO SupportAdd DWARF support to yaml2objImprove hot cold splitting to aggressively outline small blocksAdvanced Heuristics for Ordering Compiler Optimization PassesMachine learning and compiler optimizations: using inter-procedural analysis to select optimizationsAdd PostDominatorTree in LoopStandardAnalysisResultsCreate loop nest passInstruction properties dumper and checkerUnify ways to move code or check if code is safe to be moved Clang****LLDBSupport autosuggestions in LLDB's command lineImplement the missing tab completions for LLDB's command lineReimplement LLDB's command-line commands using the public SB API.Add support for batch-testing to the LLDB testsuite.- MLIR- See the MLIR open project list

• See the

Google Summer of Code 2019- LLVM Core Clang

Google Summer of Code 2018Google Summer of Code 2017 Welcome prospective Google Summer of Code 2026 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 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 API notes are a YAML-based "sidecar" file mechanism in Clang that allows users to add attributes to existing headers without modifying the header files themselves. This is particularly useful for Swift developers who want to annotate third-party C/C++ libraries and frameworks for better interoperability. However, API notes have limited support for C++ syntax (e.g., type conversion operators), and cannot annotate specific function overloads or template instantiations. The -fbounds-safety extension for C adds bounds annotations and compiler-enforced bounds checking to prevent buffer overflow vulnerabilities. Developed by Apple and maintained in a The student will contribute to upstreaming by: - Taking a subset of features identified by the mentor

• Extracting a relevant downstream feature and refactoring to meet upstream LLVM standards, writing tests and documentation
• Backporting to the downstream fork to validate correctness in the full -fbounds-safety context The newly introduced -fmodules-driver mode enables explicit module builds directly from Clangâs driver, supporting both Clang modules discovered via module map files and C++20 named modules. Currently, these modules are precompiled from scratch on every invocation because the modules driver does not provide any caching. This is especially costly for large modules (e.g., the Standard library modules), adding substantial overhead to each compilation. This project aims to add compilation-job-level caching across the entire modules-driver build graph to enable incremental compilation. Using the dependency-scan results, the driver should track header and module dependencies for each input and determine which jobs must be rebuilt and which can be safely reused from the cache. The LLVM libc project aims to provide a complete, correct, and high-performance C23 standard library. A key differentiator is its focus on correctly rounded math functions for all floating-point types, including float, double, long double, and float128 (IEEE 754 quad precision). However, not all compilers or architectures support these types natively. For example: - MSVC on Windows treats long double as 64-bit double and lacks a native __float128 type.
• AArch64 targets typically use 128-bit long double, but lack the 80-bit extended precision format.
• Clang on certain non-x86 targets may not enable __float128 by default. This lack of host compiler support prevents LLVM libc from building and testing its high-precision math routines on these platforms. The goal of this project is to implement standalone C++ classes (e.g., within LIBC_NAMESPACE::fputil) that emulate float80 and float128 semantics in software. These classes should provide the necessary operator overloads and storage (using UInt<128> or similar) to allow the existing templated math implementations to compile and run even when the host compiler does not support the native types.
• Type Abstraction: Create wrapper classes that mimic the behavior of native floating-point types.
• Soft-Float Arithmetic: Implement or connect these classes to soft-float arithmetic routines (add, sub, mul, div) so that math algorithms (like polynomial evaluation) can be executed.
• Integration: Refactor the math function entry points to instantiate templates with these emulated types when native support is missing.
• A header-only C++ implementation of float80 and float128 types that can be used where native support is missing.
• Basic arithmetic operations (+, -, *, /) implemented for these types.
• Demonstration of LLVM libc math functions compiling and passing tests using these emulated types on a target that lacks native support (e.g., building float80 math on Mac arm64, float128 math with MSVC).
• Basic C++ skills.
• Interest in understanding the intricacies of floating-point formats (IEEE 754 and extended precision). compiler-rt builtins provide essential floating-point computation routines to support runtime execution when the underlying hardware does not support specific floating-point types natively. Unfortunately, the current implementations are under tested, leaving subtle numerical bugs lying dormant for years. Additionally, they are written in a mix of C and hand-written assembly, which substantially increases the maintenance burden. In contrast, LLVM libc implements these basic floating-point operations with rigorous testing and formal verification. A recent Our goal is to demonstrate the feasibility and benefits of replacing legacy compiler-rt floating-point builtins with the modern, verified equivalents from LLVM libc.
• Infrastructure: Ensure basic floating-point operations in LLVM libc are exposed as shared, free-standing headers suitable for inclusion in compiler-rt.
• Integration: Add a CMake build option allowing compiler-rt builtins to be compiled using LLVM libc math routines instead of the legacy implementations.
• Validation & Performance: Benchmark the new implementation on embedded targets. Analyze code size and performance, optimizing the build to achieve parity with the current C or hand-written assembly implementations.
• Basic C++ skills.
• Interest in understanding the intricacies of floating-point formats (IEEE 754) and the low-level implementation of arithmetic operations. Modern heterogeneous applications rely heavily on GPU offloading, yet todayâs compilation pipelines strictly separate host and device compilation. This separation prevents whole-program reasoning across hostâdevice boundaries and limits optimization opportunities such as kernel specialization, launch-bound inference, and cross-boundary constant propagation. This project proposes extending The Clang compiler today emits separate compilation artifacts for host and device code (e.g., CUDA/HIP). While this model simplifies handling, it introduces fundamental limitations: - No cross-boundary analysis: The compiler cannot reason about kernel launches, argument values, or launch configuration at the call site.
• Missed optimization opportunities: Kernel specialization, dead code elimination, and launch-bound inference require joint hostâdevice visibility. LLVMâs MLIR-based CIR provides a unique opportunity to address this limitation. Because both host and device code are represented in a structured, high-level IR, it becomes feasible to temporarily merge them, perform joint analyses and transformations, and then re-split them for conventional lowering. This project directly explores that opportunity.<\p> ClangIR is actively being upstreamed and already supports emitting CIR from Clangâs AST and lowering to LLVM IR. Initial experiments have demonstrated that host and device CIR modules can be merged in a controlled way. A work-in-progress implementation already exists which is capable of merging but there is still work to be done in incorporating the merging with the clang driver - A WIP PRon the incubator project presenting some of the required steps - An issueloosely tracking changes regarding the offload support on ClangIR.
• Clang Driver extensions to optionally enable the capability.
• Build the infrastructure to contain within a single translation unit both device and host code
• Build the infrastructure to properly split a "combined" translation unit to individual ones representing device and host code
• End to End execution of the new driver pipeline on benchmarks from PolyBench.
• Reporting on compilation time overheads and execution time overheads.
• Bonus Point: Implement an optimization pass that infers launch bounds from the host call site
• Survey the current support gaps when using clangd for HLSL.
• Create an RFC documenting the gaps and propose the best way to address them.
• After refining the RFC, generate issues for the groundwork of implementation.
• Implement these issues to complete HLSL support in clangd. We do not expect all issues to be resolved and for full support of HLSL to be in clangd. It is however expected that the first 3 steps take ~90 hrs, and the remaining ~90 hrs are dedicated towards implementation. Required: - Intermediate proficiency of C++.
• Familiarity of how Language Server Protocols (LSP) work.
• Interest in learning/knowing the HLSL language specification. Desired: - Previous experience programming with HLSL is a plus.
• Previous experience developing with LSPs is a plus. Medium (~180hr). Medium. 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 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 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. frame #0: 0x0000000100000f80 a.outmain(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.outmain: ... 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")to produce output like this, where we annotate when a variable is live and what its location is: (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.
• Adrian Prantl aprantl@apple.com (primary contact)
• Jonas Devlieghere jdevlieghere@apple.com 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. medium (~175h) hard
• 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. Basic C & C++ skills + Interest in knowing / learning more about the delicacy of floating point formats. Modern GPUs are capable of unified addressing with the host. We currently use this to provide I/O support using the This interface is a ring buffer designed to accelerate syscalls. However, it provides a
• An implementation of pwrite andpread that runs on the GPU. - Support for printf by forwardingsnprintf intopwrite . - If time permits, exploring GPU file APIs. Basic C & C++ skills + access to a GPU, Linux kernel knowledge, GPU knowledge. The LLVM C library provides implementations of math functions. We want to profile these against existing implementations, such as CUDA's 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
• Final performance results similar to Old resultsbut with the more optimized functions and higher accuracy. - A test suite that can do brute force testing to confirm that the implementations are conformant. Basic C & C++ skills + access to a GPU, some math knowledge 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.
• Build the infrastructure to run tests and collect results.
• Present the results in a way that can be placed on a webpage.
• 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. 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.
• Migrate ClangIR support for C and C++ language features into the main LLVM repository
• Improve the quality of code as it is being migrated
• Suggest ways to improve the migration process
• Identify the checks that can benefit from the [[clang::lifetimebound]] and[[clang::lifetime_capture_by(X)]] annotations. - Extend those checks to support these annotations.
• Make sure the generated bug reports are high quality, the diagnostics properly explain how the analyzer took these annotations into account.
• Validate the results on real world projects.
• Potentially warn about faulty annotations (stretch goal). 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. Invoking clang similarly to clang -o program -std=c++20 main.cpp A.cppm B.cppmshould compile successfully where each translation-unit only imports modules defined in other source files on the command line, or the standard library. This should add no overhead to cases where modules are not used. Intermediate knowledge of C++; familiarity with how C++ code is built. Familiarity with C++20 modules is an asset, but not required. medium (~175h) medium 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=undefinedflag 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_trapwork to encode the reason for trapping ("trap reasons") inside the debug information. If time permits we can also investigate emitting more precise trap reasons
• When the -fsanitize-trap=undefinedflag 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_trapworks. - 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). Good understanding of C++
• Familiarity with UBSan
• Familiarity with LLDB small (~90h). but can be extended if time allows 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. -Wdocumentationwhich can be used to validate the content of documentation comments during compilation). Unfortunately, Clangâs documentation parser is incomplete and has several issues: - 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. 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 The online compiler 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. Intermediate knowledge of Rust and C++; Familiarity with profilers or LLVM metadata is an asset, but not required. medium (~175h) medium 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. 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 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. 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.
• 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. 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 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 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
• Replace known patterns such as branch on undef/poison, memory accesses with invalid pointers, etc with non-UB patterns.
• Use Alive2 to detect further patterns (by searching for tests that are always UB).
• Report any LLVM bug found by Alive2 that is exposed when removing UB.
• 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.
• Add the intrinsics to LLVM IR.
• Implement legalization/expansion support in SelectionDAG and GlobalISel.
• Implement optimization support in ConstantFolding, InstSimplify, InstCombine, CorrelatedValuePropagation, IndVarSimplify, ConstraintElimination, IPSCCP, and other relevant transforms.
• Make use of the intrinsics via InstCombine canonicalization or direct emission in clang/rustc.
• 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. // 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; } This pathological example expands to 37253 lines of code to process. Cling builds an index (it calls it an autoloading map) where it contains only forward declarations of these C++ entities. Their size is 3000 lines of code. The index looks like: // 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; Upon requiring the complete type of an entity, Cling includes the relevant header file to get it. There are several trivial workarounds to deal with default arguments and default template arguments as they now appear on the forward declaration and then the definition. You can read more in [1]. Although the implementation could not be called a reference implementation, it shows that the Parser and the Preprocessor of Clang are relatively stateless and can be used to process character sequences which are not linear in their nature. In particular namespace-scope definitions are relatively easy to handle and it is not very difficult to return to namespace-scope when we lazily parse something. For other contexts such as local classes we will have lost some essential information such as name lookup tables for local entities. However, these cases are probably not very interesting as the lazy parsing granularity is probably worth doing only for top-level entities. Such implementation can help with already existing issues in the standard such as CWG2335, under which the delayed portions of classes get parsed immediately when they're first needed, if that first usage precedes the end of the class. That should give good motivation to upstream all the operations needed to return to an enclosing scope and parse something. Implementation approach: Upon seeing a tag definition during parsing we could create a forward declaration, record the token sequence and mark it as a lazy definition. Later upon complete type request, we could re-position the parser to parse the definition body. We already skip some of the template specializations in a similar way [2, 3]. Another approach is every lazy parsed entity to record its token stream and change the Toks stored on LateParsedDeclarations to optionally refer to a subsequence of the externally-stored token sequence instead of storing its own sequence (or maybe change CachedTokens so it can do that transparently). One of the challenges would be that we currently modify the cached tokens list to append an "eof" token, but it should be possible to handle that in a different way. In some cases, a class definition can affect its surrounding context in a few ways you'll need to be careful about here: 1) struct X appearing inside the class can introduce the name X into the enclosing context. 2) static inline declarations can introduce global variables with non-constant initializers that may have arbitrary side-effects. For point (2), there's a more general problem: parsing any expression can trigger a template instantiation of a class template that has a static data member with an initializer that has side-effects. Unlike the above two cases, I don't think there's any way we can correctly detect and handle such cases by some simple analysis of the token stream; actual semantic analysis is required to detect such cases. But perhaps if they happen only in code that is itself unused, it wouldn't be terrible for Clang to have a language mode that doesn't guarantee that such instantiations actually happen. Alternative and more efficient implementation could be to make the lookup tables range based but we do not have even a prototype proving this could be a feasible approach.
• 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
• 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. 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. frame #0: 0x0000000100000f80 a.outmain(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.outmain: ... 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")to produce output like this, where we annotate when a variable is live and what its location is: (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.
• Adrian Prantl aprantl@apple.com (primary contact)
• Jonas Devlieghere jdevlieghere@apple.com 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. medium (~175h) hard 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. A tool to reduce GPU errors without loosing the original error. Optionally, other properties could be the focus of the reduction, not only errors.
• Parasyris, Konstantinos parasyris1@llnl.gov
• Johannes Doerfert jdoerfert@llnl.gov 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 medium medium 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 Improvements to the prototype support of offloading in libcxx. Evaluations against other offloading approaches and documentation on the missing parts and shortcommings.
• Johannes Doerfert jdoerfert@llnl.gov
• Tom Scogland scogland1@llnl.gov
• Tom Deakin tom.deakin@bristol.ac.uk 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. large medium 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". Statistical evidence on the impact of various thresholds inside of LLVM's code base, including compile time changes, impact on transformations, and performance measurements.
• Jan Hueckelheim jhueckelheim@anl.gov
• Johannes Doerfert jdoerfert@llnl.gov
• William Moses wmoses@mit.edu Required: - Profiling skills and knowledge of statistical reasoning Desired: - Good understanding of the LLVM code base and optimization flow medium easy 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. In-depth performance for libc functions. Overhead of GPU-to-CPU remote procedure calls. More optimal implementations of 'libc' functions.
• Joseph Huber joseph.huber@amd.com
• Johannes Doerfert jdoerfert@llnl.gov Required: - Profiling skills and understanding of GPU architecture Desired: - Experience with libc utilities small easy More efficient GPU First framework that can support both NVIDIA and AMD GPUs. Optionally, upstream the framework.
• Shilei Tian i@tianshilei.me
• Johannes Doerfert jdoerfert@llnl.gov
• Joseph Huber joseph.huber@amd.com 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 medium medium The 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 A good starting point for this work is the GEMM |