Explore Projects

Many HPC applications rely on GPUs for fast and efficient computation. At the same time, there is an effort to bring more programmability and portability when writing code for the GPU. One of such efforts is the implementation of the libc and libc++ in LLVM project for execution on the accelerator itself. This allows standard host applications to run on the GPU automatically, without modification to the user code. One consideration of such an approach is that some functions are not natively supported on the GPU and rely on RPC calls to the host. This poses a limitation on the bandwidth of data transfer. Thus, this project aims to improve current file operations triggered by GPU, leveraging the new Linux io_uring interface. io_uring allows the program to register a queue to asynchronously request file operations and pool the completion by interacting with such a queue. Apart from registering the queue, requesting and polling operations do not require a syscall, making it faster and more flexible than regular POSIX operations or Linux AIO calls. We will map and register/pin a memory region on the GPU side and use that region for io_uring interaction, driven by the GPU. We expect such a process to deliver more performance than current RPC round-trips to complete I/O transfers, which require a CPU polling thread for each request and do not come close to the theoretical bandwidth of PCIe interfaces.

Clang-Doc is a documentation generator developed on top of libtooling developed as an alternative to Doxygen. Development started in 2018, and continued through 2019, however it has since stalled. Currently, the tool can generate HTML and markdown but the generated output has usability issues. Issues include, not supporting all C++ constructs, lack of ability to render in markdown and many more. This project aims to address the pain points regarding Clang-Doc, which will improve the output of Clang-Doc significantly.

When a separate executor process is used with LLVM JIT, the generated code needs to be transferred to the executor process which is done by the JITLinkMemoryManager. The current implementation uses ExecutorProcessControl API (an RPC scheme) to send the generated code which goes through pipes or network sockets. The goal of the project is to transfer it through an operating system provided shared memory regions for better performance, when both the JIT process and the executor process are sharing the same underlying physical memory. It should be done by allocating large chunks of memory and distributing it to reduce memory allocation overheads and inter process communication.

<p>To implement the missing tab completions for LLDB's command line as the title goes, I dug out possible commands as targets and provided a list of implementation solutions for them. Things remained are coding and testing.</p>

<p>The project aims to improve the LLDB curses GUI to provide a complete and intuitive IDE-like debugging experience without having to resort to the command line interface.</p>

<p>The goal of this project is to provide a new option in the clang static analyzer to validate (or refute) reported bugs, by using an SMT solver. The implementation consists of an extra step, after the bug is found by the built-in solver (RangedConstraintManager) but before reporting it to the user; the path and the constraints that trigger the bug will be encoded in SMT and checked for satisfiability using the SMT solver Z3. The expected result of the project is to reduce the number of false bugs reported by the analyzer and evaluate the overhead introduced by Z3 during validation.</p>

<p>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. 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.</p> <p>At the end of this Google Summer of Code project, Enzyme should be able to automatically calculate the optimal derivatives of several common linear algebra functions, thereby implicitly allowing easier integration of Enzyme in several mathematical computing libraries.</p>

<p>The project aims at providing the MergeFunctions pass in LLVM to have feature parity with the MergeSimilarFunctions pass, which can merge functions which are similar beyond a user specified similarity threshold. It also deals with providing MergeFunctions pass with ThinLTO support, thereby gaining in the code size optimisation.</p>

<p>The Polyhedral framework provides an exact dependence analysis, which is more powerful than conventional dependence testing algorithms. Currently, LLVM mainline lacks a powerful dependence analysis framework, and at the same time, Polly’s (a high level data locality optimizer based on polyhedral framework) dependence analysis is suitable for many transformation passes in LLVM like Loop Vectorization, Loop Versioning, Modulo Scheduling, Loop Nest Optimizations, etc. I want to provide an API to Polly such that its precise dependence analysis can be used as an Analysis pass within LLVM's transformation passes.</p>

<p>In C++, virtual functions let instances of related classes have different behavior at run time. Pure function called from constructors and destructors will make the C++ program crash and virtual function called from constructors and destructors may not do what you expect. This proposal is about implementing a path-sensitive checker to find virtual calls made from constructors and destructors.</p>

<p>A Module System for C++ is on its way to the C++ standard.</p> <p>The current state of the Module System, although fairly stable, it has a few bugs for C++ support. The most common reason for the bugs is the semantic merging of C++ entities. Currently, the method for ensuring no regressions is a buildbot for libc++, which builds llvm in modules self-hosted mode. Its main purpose is to find bugs in clang’s implementation and ensure no regression for the ongoing development.</p> <p>Since the Module Systems is meant to be generic, the project aims to improve the stability and coverage of the Module System by finding as many issues as possible. One approach is to add a buildbot for libstdc++, because this would change the merging model for the modules, and in this way, it will point out different issues which would not be observed by using libc++. The choice for libstdc++ is motivated by its wider use in Unix and, more importantly, the benefits it will bring to supporting modules for third party projects that rely on libstdc++.</p>

This project aims to allow using dynamically loaded Clang plugins on windows by adding support for building LLVM and Clang as shared libraries on Windows with all the public c++ API exported and dynamically linking to them. Part of the process will be automated with a tool built using the Clang tooling API to automatically add export macros on the appropriate class and functions declarations in llvm public headers. Deliverables: End users can use custom clang plugins with official windows build of Clang. The llvm windows binary install size can be greatly decreased by dynamically linking llvm tools to the LLVM and Clang shared libraries.

Clang-REPL enables developers to program in C++ in an exploratory manner via a read-eval-print-loop. Developers, however, have to type each letter or symbol in the REPL, which likely causes typos. The auto-completion we are proposing aims to assist developers in avoiding that laborious typing, and it is also type-directed in that completion candidates are well-typed with respect to cursor positions. The project incorporates the completion infrastructure of Cling into Clang-REPL. Next, we build components that handle type contexts and subtyping. Lastly, we combine the completion and type-related components to deliver the type-directed auto-completion in Clang-REPL.

LLVM currently lacks a type capable of representing raw memory, similar to unsigned char, char and std::byte in C/C++. The absence of such a type is the root cause of many unsound optimizations, such as the lowering of calls to memcpy/memmove/memcmp to integer loads of the corresponding bitwidth. This optimization is incompatible with the use of pointer provenance, as loading a pointer from memory as an integer discards provenance information, leading to miscompilations. This project aims to introduce a new byte type to the IR, capable of representing raw memory, and lower the char, unsigned char and std::byte C/C++ types to the new type. It also addresses the incorrect lowerings of memory related intrinsics, providing a way to natively implement such intrinsics in the IR, fixes optimizations that do not correctly account for type punning, and adds support for the byte type in the Alive2 optimization verifier.

This project aims to develop tutorials demostrating the current capabilities of clang-repl. It also aims to investigate and research the requirements for adding clang-repl as a backend to xeus-cling. Add support for Xeus with the newly added clang-repl which is inspired from cling. The need for clang-repl is that it presents opportunities for rigorous open source development. However even though it is inspired by cling, not all of clang-repl and cling are same i.e. they are similar but work needs to be done to add xeus protocol support for clang-repl.

JITLink is LLVM’s new JIT linker designed to support a variety of new features, which includes full static initializer, thread local storage, and small code model, that were not possible in RuntimeDyld, the old JIT linker API. 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). This project aims to implement the JITLink specialization for ELF/aarch64 and COFF/x86-64.

<p>LLVM functions, as well as arguments and other entities, can be tagged with several attributes such as the function only reads memory, or the function cannot throw exceptions. These attributes are used by many optimizations when deciding if a particular transformation is valid or not.</p>

<p>Copy-pasted code is dangerous because it introduced bugs and makes projects harder to maintain. This proposal is about creating tools for finding copy-pasted code and report bugs that are caused by this practice. These tools include a checker for clang’s static analyzer that analyses a single translation unit and a standalone tool that performs a project-wide analysis.</p>

<p>With a surge of machine learning, especially the neural network model which needs to compute a huge amount of gradients, more and more languages' users begin to call for the ability to do high-performance and convenient <em>automatic differentiation</em> (hereafter AD) on functions, whereupon many AD tools are developed, among which is Enzyme. Enzyme is made as a plugin of LLVM and synthesizes differentiated functions directly on optimized LLVM IR code, which provides it with advantages in efficiency and universality. From another aspect, Rust is an emerging high-performance and safe language. Many of its users are trying to bring machine learning to it, thus an high-performance and user-friendly AD tool needed. Enzyme is a good option for this demand. However, without a deep integration into Rust, Enzyme's user experience with Rust is not so good, and more importantly, it may suffer from performance reduction due to wasted Rust meta-information. These problems hamper Enzyme from being widely used in Rust. This project will tackle the aforementioned problems through integrating Enzyme into Rust and then provide high-performance differentiation in Rust.</p>

This project aims to enhance LLDB's disassembler by annotating machine instructions with source-level variable information, such as variable locations and lifetimes, based on debug data like DWARF. Currently, LLDB’s disassembler outputs only low-level instructions, requiring users to manually infer where source variables are located. By enriching disassembly output with variable annotations (e.g., which register or constant a variable is stored in), this project will make debugging optimized and low-level code significantly easier. The solution involves extending LLDB’s disassembly printing pipeline to query live variables at each instruction address, limited to variables that reside in CPU registers or are represented as constants, ensuring efficiency and clarity. Deliverables include: Annotated disassembly output in the LLDB command-line interface. Full test coverage against optimized and unoptimized binaries. Documentation and usage examples for developers and users. This work will be designed to be debug information format-agnostic wherever possible, making it extensible across formats like DWARF and PDB.

The current implementations of the LLVM Project, have a drawback that every language frontend that wants to support Foreign Function Interface(FFI) into C code needs to implement Application Binary Interface(ABI) handling logic by itself. This leads to tremendous duplication of efforts and leaves the chance of potential inconsistencies. The aim of this project is to create a comprehensive ABI library housed within LLVM which would encapsulate the details of various platform specific calling conventions, argument passing strategies and return value handling.

<p>In this project we will look at loop transformation heuristics, such as the unroll factor.</p>

<p>The project goal is to re-implement lldb-mi to avoid using of HandleCommand and regular expressions to parse commands results.</p>