Explore Projects

This proposal seeks to extend the build system in Clang's driver to natively support module-based builds by leveraging Clang's existing support for scanning C++20 module dependencies between source files and adding support for generating the appropriate build steps.

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

<p>A lot of GNU binutils have their equivalent in the LLVM project. As the majority of people are already accustomed to the GNU ones, it would be great to make the LLVM binutils command lines compliant. The goal of this project is that people would be able to integrate LLVM tools in their existing toolchains without any efforts, and thus increase the number of projects using LLVM binutils.</p>

<p>Optimizations have been the cause of multiple miscompilations as well. It is difficult to determine whether an optimization is correct because bugs occur in corner cases and it’s hard to test them all for each optimization. But, thanks to Alive2, we can formally check the correctness of optimizations. Many of the bugs found are related to the notion of undef and poison values in LLVM. The semantics of these values has been formalized recently, and existing optimizations are being fixed to match the semantics. For example, branching on undef is now defined as undefined behavior (UB), and several branch-related optimizations are being fixed. However, fixing some of the optimizations requires further work, mainly due to performance concerns. One representative example is loop unswitch: it is incorrect, but still unfixed because fixing it causes big regressions in some benchmarks. Our goal is to fix such miscompilations with minimal-to-no performance regression. This project will investigate what is necessary to recover slowdowns and upstream the patches to LLVM.</p>

<p>I want to implement a structural diff tool atop of clang APIs that finds changes to the AST between two versions of a file. This would enable better visualizations of changes as well as semantic-aware merge tools.</p>

<p>A function that is non-exactly defined is a function that could be replaced at link time. Usually most of the non-inlining IPOs are inhibited. For the attributor, we do fix-point analysis for attributes and if we found the function to which the abstract attribute is related has non-exact definition, we immediately reach pessimistic fix-point without analyzing it. However, many of the LLVM IR functions are non-exact, so we propose a way to "wrap" the function up, so that the function can be seen as if it has exact definition, and by doing so, we can do fix-point analysis on this function</p>

This project aims to improve the reward signal used in the RL-based training of MLGO models. I plan to integrate an existing GNN-based performance estimation model into the training process to generate said reward signal, with some key improvements to facilitate better modelling of the execution environment and runtime related behaviors, such as branch mispredictions and cache misses. An outline of those improvements would be to create a corpus of blocks with a variety of enhancements over the original (first deliverable), modifying the model to be compatible with the new dataset (second deliverable), and experiment with feeding the model additional context beyond what is available within individual basic blocks to allow the model to factor in aforementioned runtime behaviors to gain valuable insights on where to go forward.

ClangIR is a new, MLIR-based intermediate representation of C and C++ code. It has been developed in an LLVM incubator project, but work is now underway to migrate the code from the incubator to the main LLVM repository. The goal for this project is to upstream the VectorType, ComplexType and Exception handling

<p>The idea is to improve the Clang Static Analyzer so that it is useful for developers who work on Clang and LLVM themselves, as well as on other LLVM-based projects, like Swift. LLVM makes use of C++ language features that the Static Analyzer has not yet been taught to understand. The analyzer also has false positives on some C++ idioms commonly used in the LLVM codebase.</p>

<p>LLVM offers 2 useful YAML tools, yaml2obj and obj2yaml. The former one reads YAML files and emits object files, e.g., ELF, COFF and MachO. The latter one does the reverse, reads object files and emits YAML files. We use these tools to write unit tests for binary tools, e.g., llvm-objdump, llvm-nm, llvm-readelf, as YAML is easier to read and edit than raw assembly codes and pre-built binaries. More importantly, YAML keeps our tests code base maintainable. However, yaml2obj currently doesn’t support generating DWARF sections very well (we have to hardcode the Content field of DWARF sections and it is not intuitive). This project aims to add DWARF support for yaml2obj (ELF part), which will ease our pain crafting DWARF tests.</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>

This project aims to implement a daemon that serves as a build system manager for modules, providing support for explicitly built modules irrespective of the build system. By simply incorporating a single command line flag, each Clang invocation registers its translation unit with the daemon, which then scans the unit's dependencies. As translation units are registered and analyzed, the daemon constructs a dependency graph for the entire project. Concurrently, it utilizes the emerging graph to schedule and build each module's AST. This approach allows for a single, comprehensive entity to effectively coordinate and manage the build of modules throughout the entire build process.

<p>In this project we aim to improve the deduction capabilities of the Attributor framework.</p>

<p>I would like to work on ThinLTO to improve and tune performance. This will require some analysis to determine what optimizations to add, as well as implementing some known optimizations that haven’t been included yet. Specifically, I would like to add more attributes to the ThinLTO indexes’ global variable and function summaries to increase performance.</p>

This project aims to create an interactive query language for MLIR that will allow developers to dynamically query the MLIR IR. The tool will provide a REPL or command-line interface for users to query various properties of MLIR code. The goal is to create a tool similar to clang-query, with autocomplete and other features. The project's objective is to make it easier understand the MLIR IR representation, implement a REPL for executing queries over MLIR IR, and deliver a standalone tool for interactively exploring IR with common matchers. A stretch goal is to enable extracting parts of the IR matched by queries into self-contained IR snippets.

<p>The objective of this project is to implement a simple interprocedural register allocation that attempts to minimize register spill code by propagating register usage information through the program call graph. By examining the register usage information at each call site, the intraprocedural register allocator can avoid assigning registers already used in the called routines and minimizing spill code. Stretch goal for this project would be a link time register allocator. In this register allocation is deferred till linking of the code to optimize the allocation.</p>

<p>Improve inlining: using subgraph analyze and locally optimal inlining decisions</p>

This proposal outlines a continuation of the Google Summer of Code (GSoC) 2022 topic to move uninitialized memory to poison semantics. Starting with GSoC 2022 and continuing over the last year several potential solutions have been developed and shared with the community via patches and RFCs. This has helped to build further understanding of both front-end and internal LLVM limitations. Based on the latest RFC two possible semantic solutions have been identified that allow loads to migrate to poison by default and provide backward compatibility with the current load undef semantics. This is accomplished by either freezing all bits regardless of initialization state or byte-level freezing based on initialization state. By implementing both solutions real-world performance metrics and maintenance impact can be evaluated by the LLVM community. This work will increase use of poison semantics further contributing to the eventual deprecation of undef.

<p>Working on librarifying llvm-objcopy for use throughout binutils. Creating a good base for a library such that many object file formats can be added later. I think we can create a much better and more ergonomic object file library than GNU's bfd considering we can use it as an example. Also, I find C++ is much better suited for creating ergonomic and easy to use libraries than C, obviously. If the library exists internally for LLVM and by use of its binutils, then we can create a much better library. If done correctly, many of the binutils will just have to interface with the command line and with the library and do little work with the underlying object file on their own.</p>

<p>The C++ std::string class provides a c_str() method that returns a raw pointer to a string's inner character buffer. When a std::string is destroyed, the character buffer is deallocated. A common bug is to access a dangling raw pointer to the buffer after string deallocation. These "use after free" bugs can cause crashes or other unexpected behavior. This project will add a new checker to the static analyzer to find when a dangling inner string pointer is used. This will help find bugs not only with std::string and c_str() but also with LLVM's StringRef class and the new C++17 std::string_view.</p>

This project extends Clang API Notes to support overload-specific annotations for C++ member functions. Today, API Notes cannot distinguish between overloaded methods such as foo(int) and foo(double), so annotations are applied to all overloads with the same name rather than to a specific function. The project introduces overload-aware matching for C++ methods, allowing API Notes to target individual overloads based on their parameter types while preserving compatibility with existing notes. This enables more precise annotations and improves interoperability for real-world C++ APIs, such as Swift bindings. The core deliverable is a working and tested implementation for explicit-parameter overloads (Phase 1), including typed-vs-legacy handling and regression tests. The project then extends this to support const- and ref-qualified member functions (Phase 2), completing support for receiver-sensitive overloads.

<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>Parallelism is used to improve performance. In sequential languages, parallelism is introduced with parallel constructs. However, it doesn’t come without a downside. Early outlining by the frontend is preventing existing optimization passes. The intent is to enhance and improve the existing “OpenMPOpt” optimization pass, thus improving performance of parallel programs.</p>