Description of the project: Write a shared-memory based JITLinkMemoryManager.
LLVM’s JIT uses the JITLinkMemoryManager interface to allocate both working memory (where the JIT fixes up the relocatable objects produced by the compiler) and target memory (where the JIT’d code will reside in the target). JITLinkMemoryManager instances are also responsible for transporting fixed-up code from working memory to target memory. LLVM has an existing cross-process allocator that uses remote procedure calls (RPC) to allocate and copy bytes to the target process, however a more attractive solution (when the JIT and target process share the same physical memory) would be to use shared memory pages to avoid copies between processes.

Expected results:

Implement a shared-memory based JITLinkMemoryManager:
• Write generic LLVM APIs for shared memory allocation.
• Write a JITLinkMemoryManager that uses these generic APIs to allocate shared working-and-target memory.
• Make an extensive performance study of the approach.

Confirmed Mentor: Vassil Vassilev, Lang Hames

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

Project type: Large

Discourse URL

Description of the project: The LLVM BuildingAJIT tutorial series teaches readers to build their own JIT class from scratch using LLVM’s ORC APIs, however the tutorial chapters have not kept pace with recent API improvements. Bring the existing tutorial chapters up to speed, write up a new chapter on lazy compilation (chapter code already available) or write a new chapter from scratch.

Expected results:

• Update chapter text for Chapters 1-3 -- Easy, but offers a chance to get up-to-speed on the APIs.
• Write chapter text for Chapter 4 -- Chapter code is already available, but no chapter text exists yet.
• Write a new chapter from scratch -- E.g. How to write an out-of-process JIT, or how to directly manipulate the JIT'd instruction stream using the ObjectLinkingLayer::Plugin API.

Confirmed Mentor: Vassil Vassilev, Lang Hames

Desirable skills: Intermediate C++; Understanding of LLVM and the LLVM JIT in particular; Familiarity with RST (reStructed Text); Technical writing skills.

Project type: Medium

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 and MachO/x86-64, and a relatively new implementation for ELF/x86-64. Write a JITLink implementation for a missing target that interests you. If you choose to implement support for a new architecture using the ELF or MachO formats then you will be able to re-use the existing generic code for these formats. If you want to implement support for a new target using the COFF format then you will need to write both the generic COFF support code and the architecture support code for your chosen architecture.

Expected results: Write a JITLink specialization for a not-yet-supported format/architecture.

Confirmed Mentor: Vassil Vassilev, Stefan Gränitz, Lang Hames

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 type: Large

Discourse URL

Description of the project: Every developer, at some point (usually while waiting for their program to compile), has asked "Why is it taking so long?" This project is to seek an answer to this question. There exists within LLVM, and by extension CLANG, a timing infrastructure that records events within the compiler. However, its utilization is inconsistent and insufficient. This can be improved by adding more instrumentation throughout LLVM and CLANG but one must be careful. Too much instrumentation, or instrumenting the wrong things, can be confusing and overwhelming, thus making it no more useful than not enough information. The trick is to find the right places to instrument and controlling the instrumentation. Seeking out these key spots will take you through the entire compilation process, from preprocessing through to final code generation, and all phases between. As you instrument the code, you will look at the data as you evolve it, which will further direct your search. You will develop new ways to control and filter the information to allow a better understanding of where the compiler is spending its time. You will seek out and develop example test inputs that illustrate where the compiler can be improved, which will in turn, help direct your instrumenting and search. You will consider and develop ways of controlling the instrumentation to allow better understanding and detailed examination of phases of compilation. Through all of this, you will gain an understanding of how a compiler works, from front end processing, through the LLVM optimization pipeline, through to code generation. You will see, and understand, the big picture of what is required to compile and optimize a C/C++ program, and in particular, how CLANG, LLVM and LLC accomplish these tasks. Your mentors have a combined experience of approximately 25 years of compiler development and around 8 years of experience with LLVM itself to help you on your quest.

Expected results:

• Targetted expansion of the use of the existing timing infrastructure
• Identification of appropriate test inputs for improving compile time
• Identification of compile time hotspots
• New and improved methods of controlling the timing infrastructure

Confirmed Mentor: Jamie Schmeiser, Whitney Tsang

Desirable skills: C++ programming skills; CLANG/LLVM knowledge an asset but not necessary; self motivated; curiosity; desire to learn

Project type:175 or 350 hour

Difficulty Rating:Easy - Medium

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 application, or kind of application, 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 application. 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.

Mentors Tarindu Jayatilaka, Mircea Trofin, Johannes Doerfert

Discourse URL

Description of the project This project is a continuation of last year’s. In 2021, the project achieved its first milestone - separating correctness decisions from policy decisions. This opens up the possibility of replacing the latter with machine-learned ones. Rough milestones: 1) select an initial set of features and use the existing ML Guided Optimizations (MLGO) infra to generate training logs; 2) define a reward signal, computable at compile time, to guide a reinforcement learning training loop; 3) iterate through training and refine reward/feature set

Project size: either 175 or 350 hr, ideally 350 hr

Difficulty: Medium/Hard

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

Expected outcomes: policy ('advisor') interface for loop unrolling, with current heuristic as default implementation; set up feature extraction for reinforcement learning training; set up a reward metric; set up training algorithm, and iterate over policy training

Mentors Johannes Doerfert, Mircea Trofin

Discourse URL

Description of the project LLVM's inliner is a bottom-up, strongly-connected component-level pass. This places limits on the order in which call sites are evaluated, which impacts the effectiveness of inlining. We now have a functional Module Inliner, as result of GSoC2021 work. We want to call site priority schemes, effectiveness/frequency of running function passes after successful inlinings, interplay with the ML inline advisor, to name a few areas of exploration.

Project size: either 175 or 350 hr, ideally 350 hr, milestones allow for 175hr scoping

Difficulty: Medium/Hard

Skills: C/C++, some compiler experience.

Expected outcomes: Proposal and Evaluation of alternative traversal orders; evaluation of 'clustering' inlining decisions (inline more than one call site at a time); evaluation of effectiveness/frequency of function optimization passes after inlining

Mentors Kazu Hirata, Liqiang Tao, Mircea Trofin

Discourse URL

Description of the project: C and C++ programs are often composed of various object files produced from separately-compiled source files that are then linked together. When compiling one source file, knowledge that can be derived from the logic contained within the other source files would normally not be available. Link-time optimization, also known as LTO, is a way for optimization to be done using information from more than one source file.

In LLVM, LTO is achieved by using LLVM bitcode objects as the output from the "compile" step and feeding those objects into the link step. LLVM's LTO operates in conjunction with the linker. The linker is invoked by the user and the linker in turn drives LLVM's LTO when it encounters LLVM bitcode files, getting information from LTO about what symbols a bitcode object defines or references. Information about what symbols are defined in or referenced from an object is necessary for the linker to perform symbol resolution, and a linker is normally able to extract such information from regular (non-bitcode) object files.

The implied consequences of LLVM's LTO implementation with respect to linker GC (linker garbage collection) can be improved, especially for aggressive forms of linker GC with lazy inclusion of objects and sections. In particular, the symbols referenced but undefined by an LTO module are, to the linker, monolithic at the module level. At the same time, the symbols referenced but undefined by regular (non-LTO) objects are monolithic to LTO. Together, this means that the inclusion of an LTO module into the overall process potentially leads, in the linker's initial symbol resolution, to all the undefined symbols in that module being considered as referenced; in turn, additional artifacts (e.g., archive members) may be added into the resolution, which further leads to references that may resolve to symbols defined in LTO modules and a premature conclusion that the definition of these symbols are needed. This at least means potentially unnecessary codegen is being done for functions that will be garbage-collected in the end (waste of electricity and time).

We acknowledge that an ideal implementation probably involves a "coroutine" like interaction between the linker and LTO codegen where information flows back and forth; however, such an endeavour is invasive to both linkers and to LLVM.

We believe that by

• having the linker register, via an API to LTO, symbol reference "nodes" modelling the relationship between a symbol and the symbols that are referenced in turn from (the object file section containing) its linker-selected definition, and
• using that information in LTO processing,

the LTO processing will be able to effectively identify a more accurate set of LTO symbols that are visible outside of the LTO unit. The linker merely needs to identify only exported symbols and entry points (such as the entry point for an executable and functions involved in initialization and finalization).

Having the LLVM opt/codegen understand the dependency implications from the "outside world" is strictly better than the other direction: the symbols referred to by relocations in non-LTO code are pretty much fixed as compiled (whereas some references in LTO code may disappear with optimization).

Expected results:

1. Modification of the C++ LTO interface used by LLD to implement an interface to record the symbol reference dependency data (incorporating awareness of sections and comdats). This may additionally include a method to add LTO objects provisionally, simulating behaviours where linkers only add objects as needed.
2. Modification of LTO to use new symbol reference information for definitions in regular objects when visiting definitions in the IR prior to the internalization pass to discover (transitive) symbol references and record the so-referenced symbols as being visible to regular objects. This may additionally include the "late" incorporation of LTO objects added provisionally into the merged LTO module.
3. Modification of LLD (for ELF) to modify initial resolution to use the new interface as a replacement for setting VisibleToRegularObj except for entry point functions (including C++ dynamic initialization and finalization).

Confirmed Mentors: Sean Fertile, Hubert Tong, Wael Yehia

Desirable skills: Intermediate C++; basic linker concepts (e.g., symbols, sections, and relocations)

Project size: 350 hours

Difficultly: Medium/Hard

Discourse URL

Description of the project The existence of the undef value in LLVM prevents several optimizations, even in programs where it is not used. Therefore, we have been trying to move all uses of undef to poison so we can eventually remove undef from LLVM.
This project focuses on uninitialized memory: right now the semantics of LLVM is that loading a value from uninitilized memory yields an undef value. This prevents, for example, SROA/mem2reg from optimizing conditional loads as phi(undef, %x) cannot be replaced with x, as %x might be poison.
This project consists in devising a consistent semantics for uninitialized (based on existing proposals), an upgrade plan for LLVM, and implementing the changes in LLVM and clang. In clang the changes should be specific to bit-fields.
For more information see the following discussion and/or contact the mentor.
Further reading: introduction to LLVM's memory model.

Project size: 350 hr

Difficulty: Medium/Hard

Skills: Intermediate C++

Expected outcomes:

• Semantics for memory operations that removes the need for undef values
• Upgrade plan for LLVM and frontends
• Implementation of the proposed semantics in LLVM
• Implementation of auto-upgrade path for old LLVM IR files
• Implementation of fixes in clang to use the new IR features
• Benchmarking to check for regressions and/or perf improvements

Mentors: Nuno Lopes

Description of the project

Currently, all libraries inside LLVM export all their symbols publicly. When linking statically against them, the linker will remove unused symbols and this is not a problem.

When the libraries are built as shared libraries however, the number of exported symbols is very large and symbols that are meant to be internal spill into the public ABI of the shared libLLVM.so.

In this project, we’d like to change the default visibility of library symbols to “hidden”, add an annotation macro to LLVM and use the macro to gradually move the entire library in this direction. This will eventually enable building the shared libLLVM.so on Windows as well.

In practice, this means adding -fvisibility=hidden to individual libraries and annotating exported symbols with the LLVM export annotation.

We would like this work to be as unintrusive into other developer’s workflow as possible, so starting with a small internal library would be beneficial, e.g. one of the LLVM targets or IR passes.

For further reading, there is a Discourse thread avaiable that discusses the idea behind this proposal: Supporting LLVM_BUILD_LLVM_DYLIB on Windows as well as the linked Phabricator review with a patch implementing the functionality: ⚙ D109192 [WIP/DNM] Support: introduce public API annotation support None of this work has been committed yet but can be used as a starting point for this proposal.

Project size: Medium

Difficulty: Easy

Skills: Build systems, CMake, LLVM

Expected outcomes:

• Export macro implemented and commited to LLVM
• At least one internal target ported to the new export scheme

Mentors: Timm Bäder, Tom Stellard

Description of the project: When instantiating a template, the template arguments are canonicalized before being substituted into the template pattern. Clang does not preserve type sugar when subsequently accessing members of the instantiation.

    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
    

Clang should "re-sugar" the type when performing member access on a class template specialization, based on the type sugar of the accessed specialization. The type of vs.front() should be std::string, not std::basic_string<char, [...]>.

Suggested design approach: add a new type node to represent template argument sugar, and implicitly create an instance of this node whenever a member of a class template specialization is accessed. When performing a single-step desugar of this node, lazily create the desugared representation by propagating the sugared template arguments onto inner type nodes (and in particular, replacing Subst*Parm nodes with the corresponding sugar). When printing the type for diagnostic purposes, use the annotated type sugar to print the type as originally written.

For good results, template argument deduction will also need to be able to deduce type sugar (and reconcile cases where the same type is deduced twice with different sugar).

Expected results: Diagnostics preserve type sugar even when accessing members of a template specialization. T<unsigned long> and T<size_t> are still the same type and the same template instantiation, but T<unsigned long>::type single-step desugars to 'unsigned long' and T<size_t>::type single-step desugars to 'size_t'.

Confirmed Mentor: Vassil Vassilev, Richard Smith

Desirable skills: Good knowledge of clang API, clang's AST, intermediate knowledge of C++.

Project type: Large

Discourse URL

Description of the project: Even though a lot of new C++ features are supported by the static analyzer automatically by the virtue of clang AST doing all the work under the hood, the C++17 "structured binding" syntax

    auto [x, y] = ...;

requires some extra work on the Static Analyzer side. The analyzer's transfer functions need to be taught about the new AST nodes, BindingDecl and DecompositionDecl, to work correctly in all three interpretations described by the Standard.

Incomplete support for structured bindings is a common source of false positives in the uninitialized variable checker on modern C++ code, such as #42387.

It is likely that the Clang CFG also needs to be updated. Such changes in the CFG may improve quality of clang warnings outside of the Static Analyzer.

Expected results: The Static Analyzer correctly models structured binding and decomposition declarations. In particular, binding variables no longer appear uninitialized to the Static Analyzer's uninitialized variable checker.

Confirmed Mentor: Artem Dergachev, Rashmi Mudduluru, Gábor Horváth, Kristóf Umann

Desirable skills: Intermediate knowledge of C++. Some familiarity with Clang AST and/or some static analysis background.

Project size: 350 hr

Difficulty: Medium/Hard

Discourse URL

Description: Clang Diagnostics, which issues Warnings and Errors to the programmer, are a critical feature of the compiler. Great diagnostics can have a significant impact on the user experience of the compiler and increase their productivity.

Recent improvements in GCC [1] [2] shows that there is significant headroom to improve diagnostics (and user interactions in general). It would be a very impactful project to survey and identify all the possible improvements to clang on this topic and start redesigning the next generation of our diagnostics.

In addition, we will also make conclusions on issues reported on the LLVM Github Issue page labeled with clang-diagnostics and if they need fixing, we will prepare patches otherwise simply close them.

Expected outcomes: Diagnostics will be improved:

• Improve diagnostic aesthetics
• Cover missing diagnostics
• Reduce false positive rate
• Reword diagnostics

Confirmed Mentor: Aaron Ballman, Erich Keane, Shivam Gupta

Desirable skills: C++ coding experience

Project type: Large/350 hr

Discourse URL

Description of the Project: While the standard Polly-enabled -O1/-O2/-O3 optimization pass pipelines work fine with the New Pass Manager (NPM), some parts of Polly still only works with the legacy pass manager. This includes some passes such as -polly-export-jscop/-polly-export-jscop, regression testing, Polly-ACC, command line options such as -polly-show, the PassInstrumentation mechanism used by e.g. -print-after-all. LLVM (and Clang) have moved to NPM being the default and support for the legacy pass manager is deprecated, slowly degenerates and features getting removed. That is, all of Polly's functionality should eventually work with the NPM as well, and be prepared for the complete removal of the legacy pass manager. More details about the two pass managers found here.

Expected results: The goal is to make Polly more usable with using only the NPM. Milestones, not necessarily all to be reached in this GSoC, are:
1. Make all of Polly's functionality available in the NPM (or decide to deprecate/remove it)
2. Better integration into the NPM (such as supporting PassInstrumentation); If the NPM turns out to be inadequate, use only a monolothic function pass.
3. Replace the legacy pass manager in regression tests.
4. Be ready for complete removal of the legacy pass manager in LLVM.

Confirmed mentor: Michael Kruse

Desirable skills: Understanding of the C++ template pattern used by the new pass manager (CRTP, Mixins, etc). Familarity with how LLVM can be linked (static, BUILD_SHARED_LIBS, and SHLIB/DYLIB) and its plugin loading machanisms (static, -load and -load-pass-plugin). Ideally, already worked with LLVM's new pass manager.

Project size: Medium

Difficulty: Medium/Hard

Discourse URL

Description of the project: Enzyme performs automatic differentiation (in the calculus sense) of LLVM programs. This enables users to use Enzyme to perform various algorithms such as back-propagation in ML or scientific simulation on existing code for any language that lowers to LLVM. The support for an increasing number of LLVM Versions (7-main), AD modes (Reverse, Forward, Forward-Vector, Reverse-Vector, Jacobian), and libraries (BLAS, OpenMP, MPI, CUDA, ROCm, ...) leads to a steadily increasing code base. In order to limit complexity and help new contributors we would like to express our core logic using LLVM Tablegen. The applicant is free to decide how to best map the program transformation abstractions within Enzyme to Tablegen.

Expected results: 1. A working tablegen rule generation system within Enzyme
2. Moving several existing rules to the new autogenerated system (e.g. LLVM instructions, LLVM intrinsics, BLAS calls, MPI calls, ...

Confirmed mentor: William Moses, Valentin Churavy

Desirable skills: Good knowledge of C++, calculus, and LLVM and/or Clang, and/or MLIR internals. Experience with Tablegen, Enzyme or automatic differentiation would be nice, but can also be learned in the project.

Project size: Large

Difficulty: Medium

Discourse URL

Description of the project: Enzyme performs automatic differentiation (in the calculus sense) of LLVM programs. This enables users to use Enzyme to perform various algorithms such as back-propagation in ML or scientific simulation on existing code for any language that lowers to LLVM. Enzyme already implements forward and reverse mode automatic differentiation. Enzyme also implements vector forward mode automatic differentiation, which allows Enzyme to batch the derivative computation of several objects in a single call. The goal of this project is too extend this capability in order to perform vector reverse mode. In doing so, multiple sweeps of reverse mode automatic differentiation can be performed at the same time, reducing memory, time, and otherwise generally enabling further optimization.

Expected results: Vectorized version of reverse mode automatic differentiation

Confirmed mentor: William Moses, Tim Gymnich

Desirable skills: Good knowledge of C++ and some experience with LLVM API's. Experience with Enzyme or automatic differentiation would be nice, but can also be learned in the project.

Project size: Medium

Difficulty: Medium

Discourse URL

Description of the project: Enzyme is a compiler plugin for LLVM that performs automatic differentiation (in the calculus sense) of LLVM programs. This enables users to use Enzyme to perform various algorithms such as back-propagation in ML or scientific simulation on existing code for any language that lowers to LLVM.
Enzyme integrates into frontends through the use of an LLVM plugin that can be loaded into Clang, LLVM (opt), the linker (lld), libraries (HIPRtc), directly loaded (Julia), among others (Flang, Rust, etc).
While using various pieces of machinery from the new pass manager internally, Enzyme does not currently automatically register its transformation passes when using the new pass manager. This creates problems for users on LLVM 13 or above, where the new pass manager is run by default and may not understand why they get linker errors from their code not being differentiated (currently they must add a flag to specify the old pass manager).
The goal of this project is to enable Enzyme to be called by the new pass manager in LLVM and generally create a coherent user experience.

Expected results: 1. Enzyme can be called by the new pass manager
2. [Optional] Additional syntactic sugar that makes it easier to use Enzyme.

Confirmed mentor: William Moses, Valentin Churavy

Desirable skills: Good knowledge of C++, and LLVM. Experience with Enzyme would be nice, but can also be learned in the project.

Project size: Small

Difficulty: Medium

Discourse URL

Welcome prospective Google Summer of Code 2021 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. You must propose your idea to the LLVM community through our developers' mailing list (llvm-dev@lists.llvm.org or specific subproject mailing list). 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: The LLVM lit test suites consist of thousands of small independent tests. Due to the number of tests, it can take a long time to run the full suite, even on a high-spec computer. Builds are already distributable across multiple computers available on the same network, using software such as distcc or icecream, so running tests on a single machine becomes a potential bottleneck. One way to speed up running of the tests could be to distribute test execution across many computers too. Lit provides a test sharding mechanism, which allows multiple computers to run parts of the same testsuite in tandem, but this currently assumes access to a single common filesystem, which may not be possible in all cases and a knowledge of which machines the suite can currently be run on. This project’s goal is to update the existing lit harness (or write a wrapper around it) to allow distribution of the tests in this way, with the idea that developers can write their own interface between the harness and the distribution system of their choice. This harness may need to be able to identify test dependencies such as input files and executables, send the tests to the distribution system (possibly in batches), and receive, collate and report the results to the user, in a similar manner to how lit already does.

Expected results: An easy to use harness as described above. Some evidence that given a distributed system, a user can expect to see test suite execution to speed up if they are using that harness.

Confirmed mentor: James Henderson

Desirable skills: Good knowledge of Python. Familiarity with LLVM lit testing. Some knowledge of distribution systems would also be beneficial.

Description of the project: This is a short description, please reach out to Johannes (jdoerfert on IRC) and Mircea Trofin if it sounds interesting. We successfully introduced an ML framework for inliner decisions, now we want to expand the scope. In this project we will look at loop transformation heuristics, such as the unroll factor. As a motivational example we can look at a small trip count dgemm which we optimize pretty poorly. With the nounroll pragmas we do a better job but still not close to gcc. The project is open-ended and we could look at various passes/heuristics concurrently.

Preparation resources: The ML inliner framework in the LLVM code base as well as the paper. LLVM transform passes (that are based on heuristics), e.g., loop unroll.

Expected results: Measurable better performance with a learned predictor, potentially a set of "classical" heuristics derived from the ML model.

Confirmed Mentor: Johannes Doerfert, Mircea Trofin

Desirable skills: Intermediate knowledge of ML, C++, self motivation.

Description of the project: This is a short description, please reach out to Johannes (jdoerfert on IRC) if it sounds interesting. Fuzzing often reveals a myriad of bugs. CSmith (and others) showed how to do this with C-like languages and we have used LLVM-IR fuzzing in the past successfully. In this project we will apply fuzzing to new passes that are in development, e.g., the Attributor pass. We want to find and fix crashes but also other bugs, including compile time performance problems.

Preparation resources: The LLVM fuzzer infrastructure. LLVM passes that we might want to fuzz, e.g. the Attributor pass. Prior IR-Fuzzing work (https://www.youtube.com/watch?v=UBbQ_s6hNgg)

Expected results: Crashes, maybe also a way to catch non-crash bugs, including performance problems.

Confirmed Mentor: Johannes Doerfert

Desirable skills: Intermediate knowledge C++, self motivation.

Description of the project: This is a short description, please reach out to Johannes (jdoerfert on IRC) if it sounds interesting. llvm.assume is a powerful mechanism to retain knowledge. Since it inception it was improved already multiple times but there are major extensions still outstanding which we want to tackled in this project. An incomplete list of topics includes:

• range-based assumptions, design idea 3) in the RFC.
• outline arbitrary assumption/assertion code, design idea 2) in the RFC.
• side-effect free assumptions, see this review.
• more knowledge retention usages
• less interference with optimizations

Preparation resources: The llvm.assumption usage, the assumption cache, the "enable-knowledge-retention" option, the RFC and this review.

Expected results: New llvm.assume use cases, improved performance through knowledge retention, optimization based on assertions.

Confirmed Mentor: Johannes Doerfert

Desirable skills: Intermediate knowledge C++, self motivation.

Description of the project: LLVM's IR has fundamental, long-standing issues. Many are related with undefined behaviors. Others are simply a fallout from underspecification and different interpretations by diffferent people. Alive2 is a tool that detects bugs in LLVM's optimizations automatically. Using Alive2, we track bugs exposed by the unit tests on a dashboard.

Expected results: 1) Report and fix bugs detected by Alive2. 2) Pick one fundamental IR issue and make progress towards fixing it, including proposing fixes for the semantics, testing fixes to the semantics by running Alive2 over the LLVM unit tests and medium-sized programs, test performance of semantic fixes and fix performance regressions.

Confirmed Mentor: Nuno Lopes, Juneyoung Lee

Desirable skills: Intermediate C++; willingness to learn about LLVM IR semantics; experience reading papers (preferred).

Description of the project: The idea of LoopNest pass is recently added, and there are no existing passes utilizing it. Before having LoopNest pass, if you want to write a pass that works on a loop nest, you have to pick from either a function pass or a loop pass. If you chose to write it as a function pass, then you lose the ability to add loops dynamically back to the pipeline. If you decide to write it as a loop pass, then you are wasting compile time to traverse to your pass and return right away when the given loop is not the outermost loop. In this project, we want to utilize the recently introduced LoopNest pass for passes intended for loop nest and have the same ability as the LoopPass to dynamically add loops to the pipeline. In addition, improve the current implementation of LoopNestPass when necessary.

Expected results (possibilities): Utilize LoopNest Pass for some existing transformations/analyses.

Confirmed Mentors: Whitney Tsang, Ettore Tiotto

Desirable skills: Intermediate knowledge of C++, self-motivation.

Description of the project: This is a short description, please reach out to Johannes (jdoerfert on IRC) if it sounds interesting. OpenMP GPU kernels are usually lowered to native binaries, e.g., cubin, and embedded into the host object. At runtime, OpenMP "plugins" will connect with the device driver, e.g., CUDA, to load and run such embedded binary images. In this project we want to develop a new plugin that takes LLVM-IR code, optimizes the IR with kernel parameters known only at runtime, and then generates the GPU binary for consumption by other plugins. Similar to the remote offload plugin we can do this transparently to the user. In addition to the JIT infrastructure setup in the plugin we will need to embed the IR into the host object.

Preparation resources:OpenMP target offloading infrastructure, LLVM JIT infrastructure.

Expected results: A JIT-capable offload plugin which can achieve superior performance when kernel specialization is enabling optimizations.

Confirmed Mentor: Johannes Doerfert

Desirable skills: Intermediate knowledge C++, JIT compilation, self motivation.

Description of the project: Clacc and Flacc are projects to introduce OpenACC support to Clang and Flang. For that purpose, OpenACC runtime support is being developed on top of LLVM's OpenMP runtime. However, diagnostics emitted by LLVM's OpenMP runtime are expressed in terms of OpenMP concepts, and so those diagnostics are not always meaningful to OpenACC users. This project should address this issue in two steps:

1. Develop a mechanism that selects OpenACC versions of diagnostics that are emitted as a result of OpenACC-related calls into the runtime. This mechanism should be general enough that it could be used for programming languages besides OpenMP and OpenACC. One possible approach is to extend internationalization mechanisms already present in some components of the OpenMP runtime.
2. Provide OpenACC translations for existing OpenMP diagnostics. This step requires an understanding of the relationship between OpenACC and OpenMP as implemented in Clacc and Flacc.

Many components of OpenACC support that will depend upon this project have not yet been upstreamed and are under development. A high-level understanding of those efforts is helpful for this project and can be provided by the mentors. Nevertheless, this project can be completed in upstream LLVM's OpenMP runtime now independently of those efforts.

Expected results: A version of upstream LLVM's OpenMP runtime that can emit OpenACC diagnostics as needed.

Confirmed Mentors: Valentin Clement, Joel E. Denny

Desirable skills: Intermediate C++; Experience with OpenACC or OpenMP

Description of the project: Polly use algorithms from the Integer Set Library (isl), which is a library written in C. It uses reference-counting for memory management. Getting reference counting correct is much easier in C++ using RAII, therefore we created a C++ binding for isl: isl-noexceptions.h. Since then, isl also gained two official C++ bindings, cpp.h and cpp-checked.h. We would like to replace the Polly-maintained C++ bindings with the upstream bindings. Unfortunately, this is not an in-place replacement. Differences include how errors are checked, method names, which functions are considered as operator/constructor overloads and the set of exported functions. This will require changing Polly's uses of the C++ bindings and submitting patches to isl to export additional functionality needed by Polly.

Expected results: Reduce the differences between the Polly-maintained isl-noexceptions.h bindings and one of the two C++ bindings that isl supports. Due to isl-noexceptions.h exporting more functions and classes than the upstream bindings do, a complete replacement will probably be out of reach, but even reducing the differences will reduce the maintenance cost of Polly's isl-noexceptions.h.

Confirmed mentor: Michael Kruse

Desirable skills: Deep knowledge of C++, in particular RAII and move-semantics. Interest in API design. Ideally, you already wrote some library's header file. Experience with the isl library would be nice, but can also be learned in the project.

Description of the project: Enzyme performs automatic differentiation (in the calculus sense) of LLVM programs. This enables users to use Enzyme to perform various algorithms such as back-propagation in ML or scientific simulation on existing code for any language that lowers to LLVM. Enzyme does so by applying the chain rule to every instruction in every function called by the original function to be differentiated. While functional, this is not necessarily optimal for high-level matrix operations which may have algebraic properties for faster derivative computation. Enzyme also has a mechanism for specifying a custom gradient for a given function. If a custom derivative is available, Enzyme will use that rather than fallback to implementing its own. Many programs use BLAS libraries to efficiently compute matrix and tensor operations. This project would enable high-performance automatic differentiation of BLAS and similar libraries (such as Eigen) by specifying custom derivative rules for their operations.

Expected results: Efficient differentiation of BLAS and Eigen codes by writing custom derivative rules for matrix and tensor operations.

Confirmed mentor: William Moses, Johannes Doerfert

Desirable skills: Good knowledge of C++, calculus, and linear algebra. Experience with BLAS, Eigen, or Enzyme would be nice, but can also be learned in the project.

Description of the project: Enzyme performs automatic differentiation (in the calculus sense) of LLVM programs. This enables users to use Enzyme to perform various algorithms such as back-propagation in ML or scientific simulation on existing code for any language that lowers to LLVM. While this functions for any frontend that emits LLVM IR, it may be desirable to have closer integration between Enzyme and the frontend for the sake of passing additional information and creating a better user experience. Swift provides automatic differentiation through the use of specifying custom derivative rules in the front-end. Enzyme could be integrated directly with Swift, differentiating the eventual LLVM, but it would lose out on all this additional information about custom derivatives. Moreover, calling into Enzyme naiively would be without Type checking, fine AD-specific debug information, or various other nice tools that Swift provides users of AD. This project would seek to integrate Enzyme and the Swift front end to provide both a nice user-experience for swift programmers who want to use Enzyme to enable high-performance automatic differentiation, and also to allow Enzyme to take advantage of derivative-specific metadata already available in swift.

Expected results: Creation of a custom type-checked linguistic construct in Swift for calling Enzyme. Mechanisms for passing Swift's differentiation-specific metadata for use by Enzyme.

Confirmed mentor: William Moses, Vassil Vassilev

Desirable skills: Good knowledge of C++ and Swift. Experience with Enzyme or automatic differentiation would be nice, but can also be learned in the project.

Description of the project: Enzyme performs automatic differentiation (in the calculus sense) of LLVM programs. This enables users to use Enzyme to perform various algorithms such as back-propagation in ML or scientific simulation on existing code for any language that lowers to LLVM. In a variety of fields, it is desirable to compute on fixed-point values (e.g. integers) rather than floating point values. This avoid certain truncation errors that may be critical to a given application. Moreover, particular pieces of hardware may simply be more efficient on fixed point rather than floating point values. This project would seek to extend Enzyme to support differentiation of not only floating point base values, but also fixed point base values..

Expected results: Implementation of adjoints for LLVM fixed point intrinsics, requisite type analysis rules, and integration into a front-end for an end-to-end test.

Confirmed mentor: William Moses

Desirable skills: Good knowledge of C++, caclulus, and LLVM internals. Experience with Enzyme or automatic differentiation would be nice, but can also be learned in the project.

Description of the project: Enzyme performs automatic differentiation (in the calculus sense) of LLVM programs. This enables users to use Enzyme to perform various algorithms such as back-propagation in ML or scientific simulation on existing code for any language that lowers to LLVM. While this functions for any frontend that emits LLVM IR, it may be desirable to have closer integration between Enzyme and the frontend for the sake of passing additional information and creating a better user experience. This project would seek to integrate Enzyme and the Rust front end to provide a nice user-experience for Rust programmers who want to use Enzyme to enable high-performance automatic differentiation. This also potentially involves integration of LLVM plugin support/custom codegen into rustc.

Expected results: Creation of a custom type-checked linguistic construct in Rust for calling Enzyme. Mechanisms for parsing Rust's Type information (represented as debug LLVM debug info) directly into type analysis.

Confirmed mentor: William Moses

Desirable skills: Good knowledge of C++ and Rust. Experience with Enzyme or automatic differentiation would be nice, but can also be learned in the project.

Description of the project:

• Chart how much time is spent in transfer functions – including (but not limited to!) checker callbacks.
• Add llvm Statistics and Timers for quickly obtaining precise and concise dumps without external profilers. Statistics on state splits might be particularly interesting!
• Measure time spent analyzing specific stack frames. Say, how much time do we spend inlining std::string methods? This time could be saved if we add custom models for these methods instead.

Confirmed mentor: Artem Dergachev

Description of the project: CSA has a small in-house constraint solver, it is pretty trivial, but super fast. The goal is to support range-based logic for some of the symbolic operators, while keeping it linear. Additionally, a unit-test framework can be designed specifically for testing constraint solvers (right now it’s tested rather awkwardly). This project has a couple of interesting properties. It can be segmented into small chunks, and each of these chunks has a non-trivial solution. It might introduce you to a world of solvers (it is a good idea to check your ideas with some heavy-weight solver such as z3). And because the existing solver is simple, there is a myriad of possible extensions to try.

Confirmed mentor: Valeriy Savchenko

Description of the project:

• Design and integrate a new diagnostic abstraction (similar to clang::Diagnostic) to report errors, warnings and notes in a structured way.
• Allow us to differentiate between bugs (unexpected errors) and things the debugger simply doesn’t know (expected errors). Be smart about printing global errors only once. Have the ability of being verbose and have additional metadata (source location, DWARF unit, object file, etc, depending on the type of error and where it originated).
• Should be compatible and tightly integrated with the existing classes, such as the Status and CommandReturnObject.

Confirmed mentor: Jonas Devlieghere and Raphael Isemann

LLVM participation in Google Summer of Code 2020 was very successful and resulted in many interesting projects contributed to LLVM. For the list of accepted and completed projects, please take a look into Google Summer of Code website.

Description of the project: This is a short description, please reach out to Johannes (jdoerfert on IRC) if it sounds interesting. During the GSoC'19 we build the Attributor framework to improve the inter-procedural capabilities of LLVM. This is useful on its own but especially in situations where inlining is impossible or undesirable. In this GSoC project we will look at capabilities not yet available in the Attributor and for the potential to connect the Attributor with existing intra- and inter-procedural optimizations. In this project there is a lot of freedom to determine the actual tasks but we will provide a pool of smaller and medium sized tasks that can be chosen from as well.

Preparation resources: The Attributor YouTube videos from the LLVM Developers Meeting 2019 and the recording of the IPO panel from the same meeting. The Attributor framework as well as other existing inter-procedural analyses and optimizations in LLVM.

Expected results: Measurable better IPO, especially visible in cases where inlining is not an option or undesirable.

Confirmed Mentor: Johannes Doerfert

Desirable skills: Intermediate knowledge of C++, self motivation.

Description of the project: This is a short description, please reach out to Johannes (jdoerfert on IRC) if it sounds interesting. With the OpenMPOpt pass (under review) we started to teach the LLVM optimization pipeline about OpenMP parallelism encoded as OpenMP runtime calls. In this GSoC project we will look at capabilities not yet available in the OpenMPOpt pass and for the potential to connect existing intra- and inter-procedural optimizations, e.g. the Attributor. In this project there is a lot of freedom to determine the actual tasks but we will provide a pool of smaller and medium sized tasks that can be chosen from as well.

Preparation resources: The "Optimizing Indirections, using abstractions without remorse" video on YouTube from the LLVM Developers Meeting 2018. The paper "Compiler Optimizations for OpenMP" and "Compiler Optimizations For Parallel Programs" both by J. Doerfert and H. Finkel (the slides for these are potentially even more useful).

Expected results: Measurable better performance or program analysis results for parallel programs with a focus on OpenMP.

Confirmed Mentor: Johannes Doerfert

Desirable skills: Intermediate knowledge of C++, self motivation.

Description of the project: Generating debug information is one of the fundamental tasks a compiler typically fulfills. It is clear that executable generated code should not depend on the presence of debug information.

Unfortunately there are known cases in LLVM were code generation differs depending on whether debug information is enabled (`-g`) or not. These kind of bugs can lead to bad debug experience ranging from unexpected execution behaviour to the point of programs running fine in debug mode while crashing without debug information.

The issue has likely not a single cause but is triggered during different passes on different architectures. One such reason is the insertion of Call Frame Information (CFI) in the compiler backend during frame lowering and other later passes. The presence of CFI instructions seems to change instruction scheduling which therefore leads to different generated code.

Preparation resources:

• PR37728 is a meta-bug that collects several related issues of differing codegen.
• PR37240 is a bug discussing the CFI issue mentioned above.
• The following RFC discusses some possible mitigation strategies and gives some background information on the CFI issue.

Expected results:

• Write some tooling based on existing scripts to automatically generate examples of differing codegen. This is intended as a starting task to get to know the existing LLVM tools, learn to read LLVM's internal outputs etc.
• Choose one or more (depending on the difficulty) bugs that cause codegen differences and try to provide patches to fix them. We would be particularly interested in the mentioned CFI issue but working on some of the other related bugs is also absolutely fine.

Confirmed Mentors: Paul Robinson and David Tellenbach

Desirable skills: Intermediate knowledge of C++, some familarity with general computer architecture, some familarity with the x86 or Arm/AArch64 instruction set.

Description of the project: MergeSimilarFunctions pass is able to merge not just identical functions, but also functions with small differences in their instructions to reduce code size. It does this by inserting control flow and an additional argument in the merged function to account for the differences. This work was presented at the LLVM Dev Meeting in 2013 A more detailed description was published in a paper at LCTES 2014. The code was released to the community at the time. Meanwhile, the pass has been in production use at QuIC for the past few years and has been actively maintained internally. In order to magnify the impact of MergeSimilarFunctions, it has been ported to ThinLTO and the patches have been upstreamed (see stack of 5 patches mentioned below). But instead of replacing the existing MergeFunctions pass in LLVM-upstream the community suggested we improve the existing one with the ideas from MergeSimilarFunctions. And then leverage the ThinLTO on top of that. The MergeSimilarFunction used in ThinLTO gives impressive code size reduction across a wide range of workloads and the work was presented at LLVM-dev 2018. The LLVM project would greatly benefit from this code size optimization as most embedded systems (think SmartPhones) applications are constrained on code-size.

Preparation resources:

• Stack of patches:
  • MergeSimilarFunctions 1/n: a code size pass to merge functions with small differences
  • [Porting MergeSimilarFunctions 2/n] Changes to DataLayout
  • [Merge SImilar Function ThinLTO 3/n] Add hash code to function summary
  • [Merge SImilar Function ThinLTO 4/n] Make merge function decisions before the thin-lto stage
  • [Merge SImilar Function ThinLTO 5/n] Set up similar function to be imported
  The paches can be easily applied to LLVM-trunk and would give a developer a decent head start ;).
• List of llvm-dev mailing list posts on previous discussions around Merge Functions
  • Link1
  • Link2
  • Link3
  • Link4
• The original paper: LCTES 2014
• Video and slides of the presentation

Expected results:

• Improve MergeFunctions to have feature parity with MergeSimilarFunctions.
• Enable MergeFunctions to ThinLTO.

Confirmed Mentors:Aditya Kumar (hiraditya on IRC and phabricator), JF Bastien (jfb on phabricator)

Desirable skills: Course on compiler design, SSA Representation, Intermediate knowledge of C++, Familiarity with LLVM Core.

Description of the project: LLVM provides a tool called yaml2obj which coverts a YAML document into an object file, for various different file formats such as ELF, COFF and Mach-O, along with obj2yaml which does the inverse. The tool is commonly used to test parts of LLVM, as YAML is often easier to use to describe an object file than raw assembly and more maintainable than a pre-built binary. DWARF is a debugging file format commonly used by LLVM. Many of the tests for LLVM’s DWARF emission are written in assembly, but it would be nicer to write them in YAML. However, yaml2obj does not properly support emission of DWARF sections. This project is to add functionality to yaml2obj to make writing test inputs for DWARF tests simpler, particularly for ELF objects.

Preparation resources: Reading up on the DWARF file format will be useful, in particular the standards available at http://dwarfstd.org/Download.php. Also, familiarising yourself with the basics of the ELF file format, as described here https://www.sco.com/developers/gabi/latest/contents.html, may be beneficial.

Expected results: The ability to use yaml2obj to generate DWARF sections for object files. Particularly important is ensuring the input YAML can be more easily understood than the equivalent assembly.

Confirmed Mentors: James Henderson

Desirable skills: Intermediate knowledge of C++.

Description of the project: Hot Cold Splitting in LLVM is an IR level function splitting transformation. The goal of hot/cold splitting is to improve the memory locality of code and helps reduce startup working set. The splitting pass does this by identifying cold blocks and moving them into separate functions. Because it is implemented at the IR level all the back end target benefit from it. It is a relatively new optimization and it was recently presented at the LLVM Dev Meeting in 2019 and the slides are here Because most of the benefit comes from outlining small blocks e.g., __assert_rtn. The goal of this project is to identify potential blocks via static analysis e.g., exception handling code, optimizing personality functions. Use cost-model to ensure outlining reduces the code size of the caller, use tail call whenever appropriate to save instructions.

Preparation resources:

• Update on hot cold splitting
• The following two papers provide earlier work on hot cold splitting. While these papers are a good start, LLVM's HCS has completely different implementation in two aspects a) It is implemented at IR level and outlines basic blocks as function rather than naked branches. b) It is based on regions and outlines a set of basic blocks.
  • Original paper on hot cold splitting by Pettis and Hansen.Section 5 on procedure splitting is interesting one. It has nice examples ;) to help understand why HCS works.
  • Paper on hot cold splitting The paper provides some details on one approach to split functions. This is helpful to get a different perspective and may help get new ideas.
• Video and slides of the presentation

Expected results:

• Improve Hot Cold Splitting to detect and outline cold blocks from program via static analysis or profile information. Use appropriate cost model to weigh benefit of HCS. In case compile time overhead becomes quadratic, come up with a cost model to detect when quadratic behavior gets triggered and bail out based on a compiler flag.

Confirmed Mentors:Aditya Kumar (hiraditya on IRC and phabricator)

Desirable skills: Course on compiler design, SSA Representation, Intermediate knowledge of C++, Familiarity with LLVM Core.

Description of the project: Selecting optimization passes for given application is very important but non-trivial problem because of the huge size of the compiler transformation space (incl. pass ordering). While the existing heuristics can provide high performance code for certain applications, they cannot easily benefit a wide range of application codes. The goal of the project is to learn the interplay between LLVM transformation passes and code structures, then 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 application.

Expected results (possibilities):

• Insights about (implicit) dependences between existing passes.
• New pass pipelines (think -O3a, -O3b, ...) selectable by the user that tend to perform substantially better on certain kinds of programs.
• An improved LLVM pass heuristic or new machine learning-based models that can select the best order for LLVM transformation passes based on code structures.

Preparation resources:

• HERCULES: Strong Patterns towards More Intelligent Predictive Modeling, Eunjung Park; Christos Kartsaklis; John Cavazos, IEEE ICPP’14 https://ieeexplore.ieee.org/abstract/document/6957226
• Predictive Modeling in a Polyhedral Optimization Space, Eunjung Park, John Cavazos, Louis-Noël Pouchet, Cédric Bastoul, Albert Cohen & P. Sadayappan, IJPP’13 https://link.springer.com/article/10.1007/s10766-013-0241-1
• Machine Learning in Compiler Optimization, Zheng Wang and Michael O’Boyle, IEEE Magazine 2018. https://ieeexplore.ieee.org/document/8357388

Confirmed Mentors:EJ Park, Giorgis Georgakoudis, Johannes Doerfert

Desirable skills: C++, Python, experience with LLVM and learning-based prediction preferable.

Description of the project: Current machine learning models for compiler optimization select the best optimization strategies for functions based on isolated per function analysis. In this approach, the constructed models are not aware of any relationships with other functions around it (callers or callees) which can be helpful to decide the best optimization strategies for each function. In this project, we want to explore the SCC (Strongly Connected Components) call graph to add inter-procedural features in constructing machine learning-based models to find the best optimization strategies per function. Moreover, we want to explore the case that it is helpful to group strongly related functions together and optimize them as a group, instead of per function.

Expected results (possibilities):

• Improved heuristics for existing (inter-procedural) passes, e.g. to weight inlining versus function cloning based on code features.
• Machine learning models to select the best optimizations using code features and inter-procedural analysis. This model can be used for functions in isolation or groups of functions, e.g., CGSCCs.

Preparation resources:

• HERCULES: Strong Patterns towards More Intelligent Predictive Modeling, Eunjung Park; Christos Kartsaklis; John Cavazos, IEEE ICPP’14 https://ieeexplore.ieee.org/abstract/document/6957226
• Predictive Modeling in a Polyhedral Optimization Space, Eunjung Park, John Cavazos, Louis-Noël Pouchet, Cédric Bastoul, Albert Cohen & P. Sadayappan, IJPP’13 https://link.springer.com/article/10.1007/s10766-013-0241-1
• Machine Learning in Compiler Optimization, Zheng Wang and Michael O’Boyle, IEEE Magazine 2018. https://ieeexplore.ieee.org/document/8357388

Confirmed Mentors:EJ Park, Giorgis Georgakoudis, Johannes Doerfert

Desirable skills: C++, Python, experience with LLVM and learning-based prediction preferable.

Description of the project: There is currently no easy way to use the result of PostDominatorTreeAnalysis in a loop pass, as PostDominatorTreeAnalysis is a function analysis, and it is not included in LoopStandardAnalysisResults. If one adds PostDominatorTreeAnalysis in LoopStandardAnalysisResults, then all loop passes need to preserve it, meaning that all loop passes need to make sure the result is up to date. In this project, we want to modify some commonly used utilities to generate a list of updates, which can be consume by different updaters, e.g. DomTreeUpdater to update DominatorTree and PostDominatorTree, and MSSAU to update MemorySSA, etc, instead of only updating the DominatorTree. In additional, we want to change existing loop passes to preserve the PostDominatorTree. Finally, adding PostDominatorTree in LoopStandardAnalysisResults.

Expected results (possibilities): PostDominatorTree added in LoopStandardAnalysisResults, and can be used by loop passes. More common utilities change to generate list of updates to be easily obtained by different updaters.

Confirmed Mentors: Whitney Tsang, Ettore Tiotto, Bardia Mahjour

Desirable skills: Intermediate knowledge of C++, self-motivation.

Preparation resources:

Description of the project: Currently if you want to write a pass that works on a loop nest, you have to pick from either a function pass or a loop pass. If you chose to write it as a function pass, then you lose the ability to add loops dynamically back to the pipeline. If you decide to write it as a loop pass, then you are wasting compile time to traverse to your pass and return right away when the given loop is not the outermost loop. In this project, we want to create a LoopNestPass, where transformations intended for loop nest can inherit from it, and have the same ability as the LoopPass to dynamically add loops to the pipeline. In addition, create all the adaptors requires to add loop nest passes at different points of the pass builder.

Expected results (possibilities): Transformations/Analyses can be written as LoopNestPass, without compromising compile time or usability.

Confirmed Mentors: Whitney Tsang, Ettore Tiotto

Desirable skills: Intermediate knowledge of C++, self-motivation.

Preparation resources:

Description of the project: TableGen is flexible and allow the end-user to define and set common properties of records (instructions). Every target has dozens or hundreds of such instruction properties. As target code evolve, the td files become more and more complicated, it become harder to see whether the setting of some properties is necessary, even correct or not. eg: whether hasSideEffects property is correctly set on all instructions? One can manually search through the TableGen-generated files; or write some script to run TableGen and matching the output for some specific properties, but a standalone utility that can dump and check instruction properties systematically (eg: also allow target to define some verification rules) might be better from a build-process-management standpoint. This can help to find quite some hidden bugs and hence improve the overall codegen code quality. In addition, the utility can be used to write regression tests for instruction properties, which will increase the quality and precision of LLVM's regression tests.

Expected results (possibilities): A standalone llvm tool or utility that can dump and check instruction properties systematically

Confirmed Mentors: Hal Finkel, Jinsong Ji , Qingshan Zhang

Desirable skills: Intermediate knowledge of C++, self-motivation.

Description of the project: Determining whether it is safe to move code around is implemented in several transformations in LLVM (e.g. canSinkOrHoistInst in LICM, or makeLoopInvariant in Loop). Each of these implementations may return different results for a given query, making code motion safety checks inconsistent and duplicated. On the other hand, the mechanism for doing the actual code motion is also different in each transformation. Code duplication causes maintenance problems and increases the time taken to write new transformation. In this project, we want to first identify all the existing ways in loop transformations (could be function or loop pass) to check if code is safe to move, and to move code, and create a standardize way to do so.

Expected results (possibilities): A standardize/superset of all the existing ways in loop transformations of checking if code is safe to be moved and to move

Confirmed Mentors: Whitney Tsang, Ettore Tiotto, Bardia Mahjour

Desirable skills: Intermediate knowledge of C++, self-motivation.

Preparation resources:

All the items in the list of open projects are opened to GSOC. Feel free to propose your own ideas as well on Discourse.

Description of the project: The Clang Static Analyzer already knows how to prevent crashes caused by null pointer dereference in arbitrary code, however it often "gives up" when the code is too complicated. In particular, implementation details of C++ standard classes, even simple ones such as smart pointers or optionals, may be too convoluted for the Analyzer to fully understand. Moreover, the exact behavior depends on which implementation of the Standard Library is used (e.g., GNU libstdc++ or LLVM's own libc++).

We can enable the Analyzer to find more bugs in modern C++ code by teaching it explicitly about the behavior of C++ standard classes, and therefore skipping the whole process in which the Analyzer tries to understand all the implementation details on its own. For example, we could teach it that a default-constructed smart pointer is null, and any attempt to dereference it would result in a crash. The project would therefore consist in manually providing implementations for various methods of standard classes.

Expected results: We want the Static Analyzer to emit warnings when a null smart pointer dereference would occur in the code. For example:

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

We should be able to cover at least one class fully, for example, std::unique_ptr, and then see if we can generalize our results to other classes, such as std::shared_ptr or the C++17 std::optional.

Confirmed Mentor: Artem Dergachev, Gábor Horváth

Desirable skills: Intermediate knowledge of C++.

Description of the project: LLDB's command line offers several convenience features that are inspired by features of UNIX shells such as tab completions or a command history. One feature that is not implemented yet are 'autosuggestions'. These are suggestions for possible commands that the user might want to type, but unlike tab completions they are displayed directly behind the cursor while the user is typing a command. A good demonstration how this could look like are the autosuggestions implemented in fish shell.

This project is about implementing autosuggestions in LLDB's editline-based command shell.

Confirmed Mentor: Jonas Devlieghere and Raphael Isemann

Desirable skills: Intermediate knowledge of C++.

Description of the project: LLDB's command line offers several convenience features that are inspired by features of UNIX shells such as tab completions for commands. These tab completions are implemented by a completion engine that is not only used by the command line interface of LLDB, but also by graphical interfaces for LLDB such as IDEs. While the tab completions in LLDB are really useful, they are currently not implemented for all commands and their respective arguments. This project is about implementing the remaining completions for the commands in LLDB which will greatly improve the user experience of LLDB. Improving existing completions is also part of the project. Note that the completions are not static list of strings but often require inspecting and understanding the internal state of LLDB. As LLDB commands and their tab completions cover all aspects of LLDB, this project offers a great way to get an overview of all the functionality in LLDB.

Confirmed Mentor:Raphael Isemann

Desirable skills: Intermediate knowledge of C++.

Description of the project: Just as LLVM is a library to build compilers, LLDB is a library to build debuggers. LLDB vends a stable, public SB API. Due to historic reasons the LLDB command line interface is currently implemented on top of LLDB's private API and it duplicates a lot of functionality that is already implemented in the public API. Rewriting LLDB's command line interface on top of the public API would simplify the implementation, eliminate duplicate code, and most importantly reduce the testing surface.

This work will also provide an opportunity to clean up the SB API of commands that have accrued too many overloads over time and convert them to make use of option classes to both gather up all the variants and also future-proof the APIs.

Confirmed Mentor:Adrian Prantl and Jim Ingham

Desirable skills: Intermediate knowledge of C++.

Description of the project: One of the tensions in the testsuite is that spinning up a process and getting it to some point is not a cheap operation, so you'd like to do a bunch of tests when you get there. But the current testsuite bails at the first failure, so you don't want to do many tests since the failure of one fails all the others. On the other hand, there are some individual test assertions where the failure of the assertion should cause the whole test to fail. For example, if you fail to stop at a breakpoint where you want to check some variable values, then the whole test should fail. But if your test then wants to check the value of five independent locals, it should be able to do all five, and then report how many of the five variable assertions failed. We could do this by adding Start and End markers for a batch of tests, do all the tests in the batch without failing the whole test, and then report the error and fail the whole test if appropriate. There might also be a nice way to do this in Python using scoped objects for the test sections.

Confirmed Mentor: Jim Ingham

Desirable skills: Intermediate knowledge of Python.

Google Summer of Code 2019 contributed a lot to the LLVM project. For the list of accepted and completed projects, please take a look into Google Summer of Code website.

Description of the project: Adding Debug Info (compiling with `clang -g`) shouldn't change the generated code at all. Unfortunately we have bugs. These are usually not too hard to fix and a good way to discover new part of the codebase! We suggest building object files both ways and disassembling the text sections, which will give cleaner diffs than comparing .s files.

Expected results: Reduced test cases, bug reports with analysis (e.g., which pass is responsible), possibly patches.

Confirmed Mentor: Paul Robinson

Desirable skills: Intermediate knowledge of C++, some familiarity with x86 or ARM instruction set.

Description of the project: Clang contains an ASTImporter which allows moving declarations and statements from one Clang AST to another. This is for example used for static analysis across translation units and in LLDB's expression evaluator.

The current ASTImporter works as intended when moving simple C code from one AST to another. However, more complicated declarations such as C++'s OOP features and templates are not fully implemented and can cause crashes or invalid AST nodes. The bug reports related to these crashes are often filed against LLDB's expression evaluator and are rarely submited with a minimal reproducer. This makes improving ASTImporter a time-consuming and tedious task.

This project is about writing a fuzzer to proactively discover these ASTImporter bugs and provide minimal reproducers which make understanding and fixing the underlying bug easier.

A possible implementation of such a fuzzer and driver could look like this:

• Generate some source code that can be imported (either fully randomly or based on existing source code from a user-given code corpus).
• Import randomly a few declarations from this AST. The AST in which they are imported to can already be populated with declarations.
• Run Clang's code generator over our imported AST.
• If we hit an assert during the import or CodeGen steps we probably found an ASTImporter bug.
• The fuzzer driver should now reduce the size of the source code until it is as small as possible and still reproduces the crash (e.g. by running Creduce with an automatically generated test script).
• The reproducer should now be stored in a format so that it can just be copied into Clang's regression test suite for the ASTImporter (see the clang/test/Import/ directory). The reproducer must still reproduce the found bug when run as part of the test suite.

This is just one possible approach and students are welcome to submit their own ideas on how the fuzzer should operate. Approaches that allow to automatically verify more aspects of the imported AST (e.g. the source locations of AST nodes, size of RecordDecls) are encouraged. The fuzzer and driver should be implemented in C++ and/or Python.

Confirmed Mentor: Raphael Isemann, Shafik Yaghmour

Desirable skills: Intermediate knowledge of C++.

Description of the project: Clang has a newly implemented autocompletion feature which details can be found at LLVM blog. We would like to improve this by adding more flags to autocompletion, supporting more shells (currently it supports only bash) and exporting this feature to other projects such as llvm-opt. Accepted student will be working on Clang Driver, LLVM Options and shell scripts.

Expected Results: Autocompletion working on bash and zsh, support llvm-opt options.

Confirmed Mentor: Yuka Takahashi and Vassil Vassilev

Desirable skills: Intermediate knowledge of C++ and shell scripting

Google Summer of Code 2018 contributed a lot to the LLVM project. For the list of accepted and completed projects, please take a look into Google Summer of Code website.

Google Summer of Code 2017 contributed a lot to the LLVM project. For the list of accepted and completed projects, please take a look into Google Summer of Code website.

This document is meant to be a sort of "big TODO list" for LLVM. Each project in this document is something that would be useful for LLVM to have, and would also be a great way to get familiar with the system. Some of these projects are small and self-contained, which may be implemented in a couple of days, others are larger. Several of these projects may lead to interesting research projects in their own right. In any case, we welcome all contributions.

If you are thinking about tackling one of these projects, please send a mail to the LLVM Developer's mailing list, so that we know the project is being worked on. Additionally this is a good way to get more information about a specific project or to suggest other projects to add to this page.

The projects in this page are open-ended. More specific projects are filed as unassigned enhancements in the LLVM bug tracker. See the list of currently outstanding issues if you wish to help improve LLVM.

In addition to hacking on the main LLVM project, LLVM has several subprojects, including Clang and others. If you are interested in working on these, please see their "Open projects" page:

• The Clang Open Projects list.
• The Polly Open Projects list.
• The SAFECode Open Projects list.

Improvements to the current infrastructure are always very welcome and tend to be fairly straight-forward to implement. Here are some of the key areas that can use improvement...

Currently, both Clang and LLVM have a separate target description infrastructure, with some features duplicated, others "shared" (in the sense that Clang has to create a full LLVM target description to query specific information).

This separation has grown in parallel, since in the beginning they were quite different and served disparate purposes. But as the compiler evolved, more and more features had to be shared between the two so that the compiler would behave properly. An example is when targets have default features on speficic configurations that don't have flags for. If the back-end has a different "default" behaviour than the front-end and the latter has no way of enforcing behaviour, it won't work.

An alternative would be to create flags for all little quirks, but first, Clang is not the only front-end or tool that uses LLVM's middle/back ends, and second, that's what "default behaviour" is there for, so we'd be missing the point.

Several ideas have been floating around to fix the Clang driver WRT recognizing architectures, features and so on (table-gen it, user-specific configuration files, etc) but none of them touch the critical issue: sharing that information with the back-end.

Recently, the idea to factor out the target description infrastructure from both Clang and LLVM into its own library that both use, has been floating around. This would make sure that all defaults, flags and behaviour are shared, but would also reduce the complexity (and thus the cost of maintenance) a lot. That would also allow all tools (lli, llc, lld, lldb, etc) to have the same behaviour across the board.

The main challenges are:

• To make sure the transition doesn't destroy the delicate balance on any target, as some defaults are implicit and, some times, unknown.
• To be able to migrate one target at a time, one tool at a time and still keep the old infrastructure intact.
• To make it easy for detecting target's features for both front-end and back-end features, and to merge both into a coherent set of properties.
• To provide a bridge to the new system for tools that haven't migrated, especially the off-the-tree ones, that will need some time (one release, at least) to migrate..

The LLVM bug tracker occasionally has "code-cleanup" bugs filed in it. Taking one of these and fixing it is a good way to get your feet wet in the LLVM code and discover how some of its components work. Some of these include some major IR redesign work, which is high-impact because it can simplify a lot of things in the optimizer.

Some specific ones that would be great to have:

• Fix the design of GlobalAlias to not require dest type to match source type
• Redesign ConstantExpr's
• Static constructors should be purged from LLVM

Additionally, there are performance improvements in LLVM that need to get fixed. These are marked with the slow-compile keyword. Use this LLVM bug tracker query to find them.

The llvm-test testsuite is a large collection of programs we use for nightly testing of generated code performance, compile times, correctness, etc. Having a large testsuite gives us a lot of coverage of programs and enables us to spot and improve any problem areas in the compiler.

One extremely useful task, which does not require in-depth knowledge of compilers, would be to extend our testsuite to include new programs and benchmarks. In particular, we are interested in cpu-intensive programs that have few library dependencies, produce some output that can be used for correctness testing, and that are redistributable in source form. Many different programs are suitable, for example, see this list for some potential candidates.

We are always looking for new testcases and benchmarks for use with LLVM. In particular, it is useful to try compiling your favorite C source code with LLVM. If it doesn't compile, try to figure out why or report it to the llvm-bugs list. If you get the program to compile, it would be extremely useful to convert the build system to be compatible with the LLVM Programs testsuite so that we can check it into SVN and the automated tester can use it to track progress of the compiler.

When testing a code, try running it with a variety of optimizations, and with all the back-ends: CBE, llc, and lli.

Find benchmarks either using our test results or on your own, where LLVM code generators do not produce optimal code or where another compiler produces better code. Try to minimize the test case that demonstrates the issue. Then, either submit a bug with your testcase and the code that LLVM produces vs. the code that it should produce, or even better, see if you can improve the code generator and submit a patch. The basic idea is that it's generally quite easy for us to fix performance problems if we know about them, but we generally don't have the resources to go finding out why performance is bad.

The LNT perf database has some nice features like detect moving average, standard deviations, variations, etc. But the report page give too much emphasis on the individual variation (where noise can be higher than signal), eg. this case.

The first part of the project would be to create an analysis tool that would track moving averages and report:

• If the current result is higher/lower than the previous moving average by more than (configurable) S standard deviations
• If the current moving average is more than S standard deviations of the Base run
• If the last A moving averages are in constant increase/decrease of more than P percent

The second part would be to create a web page which would show all related benchmarks (possibly configurable, like a dashboard) and show the basic statistics with red/yellow/green colour codes to show status and links to more detailed analysis of each benchmark.

A possible third part would be to be able to automatically cross reference different builds, so that if you group them by architecture/compiler/number of CPUs, this automated tool would understand that the changes are more common to one particular group.

The LLVM Coverage Report has a nice interface to show what source lines are covered by the tests, but it doesn't mentions which tests, which revision and what architecture is covered.

A project to renovate LCOV would involve:

• Making it run on a buildbot, so that we know what commits / architectures are covered
• Update the web page to show that information
• Develop a system that would report every buildbot build into the web page in a searchable database, like LNT

Another idea is to enable the test suite to run all built backends, not only the host architecture, so that coverage report can be built in a fast machine and have one report per commit without needing to update the buildbots.

1. Completely rewrite bugpoint. In addition to being a mess, bugpoint suffers from a number of problems where it will "lose" a bug when reducing. It should be rewritten from scratch to solve these and other problems.
2. Add support for transactions to the PassManager for improved bugpoint.
3. Improve bugpoint to support running tests in parallel on MP machines.
4. Add MC assembler/disassembler and JIT support to the SPARC port.
5. Move more optimizations out of the -instcombine pass and into InstructionSimplify. The optimizations that should be moved are those that do not create new instructions, for example turning sub i32 %x, 0 into %x. Many passes use InstructionSimplify to clean up code as they go, so making it smarter can result in improvements all over the place.

Sometimes creating new things is more fun than improving existing things. These projects tend to be more involved and perhaps require more work, but can also be very rewarding.

Many proposed extensions and improvements to LLVM core are awaiting design and implementation.

1. Improvements for Debug Information Generation
2. EH support for non-call exceptions
3. Many ideas for feature requests are stored in LLVM bugzilla. Search for bugs with a "new-feature" keyword.

We have a strong base for development of both pointer analysis based optimizations as well as pointer analyses themselves. We want to take advantage of this:

1. The globals mod/ref pass does an inexpensive bottom-up context sensitive alias analysis. There are some inexpensive things that we could do to better capture the effects of functions that access pointer arguments. This can be really important for C++ methods, which spend lots of time accessing pointers off 'this'.
2. The alias analysis API supports the getModRefBehavior method, which allows the implementation to give details analysis of the functions. For example, we could implement full knowledge of printf/scanf side effects, which would be useful. This feature is in place but not being used for anything right now.
3. We need some way to reason about errno. Consider a loop like this:

       for ()
         x += sqrt(loopinvariant);
   

   We'd like to transform this into:

       t = sqrt(loopinvariant);
       for ()
         x += t;
   

   This transformation is safe, because the value of errno isn't otherwise changed in the loop and the exit value of errno from the loop is the same. We currently can't do this, because sqrt clobbers errno, so it isn't "readonly" or "readnone" and we don't have a good way to model this.

   The important part of this project is figuring out how to describe errno in the optimizer: each libc #defines errno to something different it seems. Maybe the solution is to have a __builtin_errno_addr() or something and change sys headers to use it.

4. There are lots of ways to optimize out and improve handling of memcpy/memset.

We now have a unified infrastructure for writing profile-guided transformations, which will work either at offline-compile-time or in the JIT, but we don't have many transformations. We would welcome new profile-guided transformations as well as improvements to the current profiling system.

Ideas for profile-guided transformations:

1. Superblock formation (with many optimizations)
2. Loop unrolling/peeling
3. Profile directed inlining
4. Code layout
5. ...

Improvements to the existing support:

1. The current block and edge profiling code that gets inserted is very simple and inefficient. Through the use of control-dependence information, many fewer counters could be inserted into the code. Also, if the execution count of a loop is known to be a compile-time or runtime constant, all of the counters in the loop could be avoided.
2. You could implement one of the "static profiling" algorithms which analyze a piece of code an make educated guesses about the relative execution frequencies of various parts of the code.
3. You could add path profiling support, or adapt the existing LLVM path profiling code to work with the generic profiling interfaces.

LLVM aggressively optimizes for performance, but does not yet optimize for code size. With a new ARM backend, there is increasing interest in using LLVM for embedded systems where code size is more of an issue.

Someone interested in working on implementing code compaction in LLVM might want to read this article, describing using link-time optimizations for code size optimization.

1. Implement a Loop Dependence Analysis Infrastructure
   - Design some way to represent and query dep analysis
2. Value range propagation pass
3. More fun with loops: Predictive Commoning
4. Type inference (aka. devirtualization)
5. Value assertions (also PR810).

1. Generalize target-specific backend passes that could be target-independent, by adding necessary target hooks and making sure all IR/MI features (such as register masks and predicated instructions) are properly handled. Enable these for other targets where doing so is demonstrably beneficial. For example:
   1. lib/Target/Hexagon/RDF*
   2. lib/Target/AArch64/AArch64AddressTypePromotion.cpp
2. Merge the delay slot filling logic that is duplicated into (at least) the Sparc and Mips backends into a single target independent pass. Likewise, the branch shortening logic in several targets should be merged together into one pass.
3. Implement 'stack slot coloring' to allocate two frame indexes to the same stack offset if their live ranges don't overlap. This can reuse a bunch of analysis machinery from LiveIntervals. Making the stack smaller is good for cache use and very important on targets where loads have limited displacement like ppc, thumb, mips, sparc, etc. This should be done as a pass before prolog epilog insertion. This is now done for register allocator temporaries, but not for allocas.
4. Implement 'shrink wrapping', which is the intelligent placement of callee saved register save/restores. Right now PrologEpilogInsertion always saves every (modified) callee save reg in the prolog and restores it in the epilog, however, some paths through a function (e.g. an early exit) may not use all regs. Sinking the save down the CFG avoids useless work on these paths. Work has started on this, please inquire on llvm-dev.
5. Implement interprocedural register allocation. The CallGraphSCCPass can be used to implement a bottom-up analysis that will determine the *actual* registers clobbered by a function. Use the pass to fine tune register usage in callers based on *actual* registers used by the callee.
6. Add support for 16-bit x86 assembly and real mode to the assembler and disassembler, for use by BIOS code. This includes both 16-bit instruction encodings as well as privileged instructions (lgdt, lldt, ltr, lmsw, clts, invd, invlpg, wbinvd, hlt, rdmsr, wrmsr, rdpmc, rdtsc) and the control and debug registers.

1. Port the Bigloo Scheme compiler, from Manuel Serrano at INRIA Sophia-Antipolis, to output LLVM bytecode. It seems that it can already output .NET bytecode, JVM bytecode, and C, so LLVM would ostensibly be another good candidate.
2. Write a new frontend for some other language (Java? OCaml? Forth?)
3. Random test vector generator: Use a C grammar to generate random C code, e.g., quest; run it through llvm-gcc, then run a random set of passes on it using opt. Try to crash opt. When opt crashes, use bugpoint to reduce the test case and post it to a website or mailing list. Repeat ad infinitum.
4. Add sandbox features to the Interpreter: catch invalid memory accesses, potentially unsafe operations (access via arbitrary memory pointer) etc.
5. Port Valgrind to use LLVM code generation and optimization passes instead of its own.
6. Write LLVM IR level debugger (extend Interpreter?)
7. Write an LLVM Superoptimizer. It would be interesting to take ideas from this superoptimizer for x86: paper #1 and paper #2 and adapt them to run on LLVM code.

   It would seem that operating on LLVM code would save a lot of time because its semantics are much simpler than x86. The cost of operating on LLVM is that target-specific tricks would be missed.

   The outcome would be a new LLVM pass that subsumes at least the instruction combiner, and probably a few other passes as well. Benefits would include not missing cases missed by the current combiner and also more easily adapting to changes in the LLVM IR.

   All previous superoptimizers have worked on linear sequences of code. It would seem much better to operate on small subgraphs of the program dependency graph.

In addition to projects that enhance the existing LLVM infrastructure, there are projects that improve software that uses, but is not included with, the LLVM compiler infrastructure. These projects include open-source software projects and research projects that use LLVM. Like projects that enhance the core LLVM infrastructure, these projects are often challenging and rewarding.

At least one project (and probably more) needs to use analysis information (such as call graph analysis) from within a MachineFunctionPass, however, most analysis passes operate at the LLVM IR level. In some cases, a value (e.g., a function pointer) cannot be mapped from the MachineInstr level back to the LLVM IR level reliably, making the use of existing LLVM analysis passes from within a MachineFunctionPass impossible (or at least brittle).

This project is to encode analysis information from the LLVM IR level into the MachineInstr IR when it is generated so that it is available to a MachineFunctionPass. The exemplar is call graph analysis (useful for control-flow integrity instrumentation, analysis of code reuse defenses, and gadget compilers); however, other LLVM analyses may be useful.

Implement an on-demand function relocator in the LLVM JIT. This can help improve code locality using runtime profiling information. The idea is to use a relocation table for every function. The relocation entries need to be updated upon every function relocation (take a look at this article). A (per-function) basic block reordering would be a useful extension.

The goal of this project is to implement better data layout optimizations using the model of reference affinity. This paper provides some background information.

Slimmer is a prototype tool, built using LLVM, that uses dynamic analysis to find potential performance bugs in programs. Development on Slimmer started during Google Summer of Code in 2015 and resulted in an initial prototype, but evaluation of the prototype and improvements to make it portable and robust are still needed. This project would have a student pick up and finish the Slimmer work. The source code of Slimmer and its current documentation can be found at its Github web page.