Explore Projects

​​Jump Label Implementation​​ aims to eliminate branch overhead in kernel code by dynamically patching JMP/NOP instructions at runtime using GCC's asm goto feature. This involves defining static branch templates (ARCH_STATIC_BRANCH_ASM for NOP cases and ARCH_STATIC_BRANCH_JUMP_ASM for JMP cases) and implementing core functions (arch_static_branch and arch_static_branch_jump) along with a runtime patching mechanism (arch_jump_label_transform). The key deliverable is near-zero-cost branch decisions, significantly improving performance for frequently checked kernel conditions like tracepoints and debugging checks. ​​Ftrace Implementation​​ provides efficient function tracing (function) and call-graph profiling (function_graph) with minimal overhead. The -pg compiler flag inserts mcount() calls that dynamically redirect to either a no-op stub (when disabled) or a full tracer (when enabled). The implementation includes dynamic redirection in mcount(), the core function tracer (ftrace_trace_function), and the extended function_graph tracer with entry/exit hooks (ftrace_graph_caller and return_to_handler). This enables deep call-stack analysis while maintaining low runtime cost when tracing is inactive, supporting dynamic kernel debugging with minimal performance impact.

This project aims to create a tool that automatically generates Python typing stubs for the Device Under Test (DUT) in cocotb-based hardware verification testbenches. By leveraging cocotb’s existing introspection capabilities, the tool will produce .pyi stub files describing the DUT’s interface – its hierarchy of modules and signals – in a statically typed fashion. These stubs will enable IDE features like auto-completion via VS Code’s Pylance and allow static type checkers such as mypy to catch errors in testbench code, significantly improving the hardware verification development experience​. The generated stubs will mirror the HDL design’s structure (with considerations for hierarchical vs. flat representations) and provide a structured abstraction of the DUT interface that can even be used for mocking or unit-testing components of the testbench. Initially, the stub generator will rely on runtime cocotb introspection only, but it will be designed with extensibility in mind, so that future enhancements (e.g., integrating a SystemVerilog language server like slang for richer type info) can be incorporated​. Over a 175-hour Google Summer of Code timeline, the project will deliver a working stub-generation utility, along with documentation, tests, and integration into the cocotb ecosystem, providing a concrete benefit to the open-source hardware verification community.

“Implementing a Code Action in Visual Studio Code to show the expansion of a Swift Macro in a peeked editor”. Swift Macros allow the generation of source code at compile time. While this provides concise code and avoids repetition of common paradigms, understanding the source code can become harder if it is unknown what the macro expands to. Visual Studio Code using the Swift Extension currently has limited ability to show the code generated by a macro by invoking a code action that replaces the macro by its generated code inside the current source file. The project’s goal is to implement a code action to show the macro-generated code without modifying the current source file. This includes the implementation of a request in sourcekit-lsp to compute the contents of the macro expansion and support in the Visual Studio Swift Extension to display that content. As a stretch goal, Visual Studio Code should also offer semantic functionality like jump-to-definition inside the macro expansion and allow the expansion of nested macros. *Deliverables*: 1. An Expand Macro Code Action in VS Code that shows the generated contents of a swift macro in a peeked editor 2. Support for Semantic Functionality such as jump-to-defintion, hover, syntax highlighting in the peeked editor 3. Allow expanding macros generated from macro in the peeked editor i.e. Nested Macro Expansion 4. Add a standard request support for other LSP-based editors giving them ability to expand macros upto the first level.

tests/run-make contains a heaping collection - 349 to be precise - of Makefiles containing ancient and difficult to understand test scripts. As a result, Rust maintainers may struggle to understand why these tests fail and how to patch their code appropriately. This project aims to rewrite these tests in robust, documented rmake.rs files, backed up by a supportive and easy to understand run-make-support support tool.

There is currently no robust and unified sparse ndarray library that is compliant with the numpy API. This prevents the substitution of sparse arrays for dense arrays when needed in many data science workflows. PyData/Sparse is a repository that presents an opportunity to address these issues. In order to do so, there needs to be a C++ implementation of a code-generation algorithm that can generate efficient code for any type of sparse tensor operation. This abstraction allows one to maintain a relatively small piece of code that enables functionality for an exponential number of different sparse array format operations. The main objective of the project is to implement, test and document the merge lattice and its related data structures and algorithms that are vital for code-generation. This will result in a generalizable code-generation algorithm that can be applied for implementing a variety of different sparse ndarray formats that work together. This will involve interfacing heavily with the existing C++ code and its implemented templates to add functionality that constructs and manipulates a merge lattice, which is a useful abstraction in code-generation for sparse tensor algebra operations. As a few stretch goals, I plan on: i) implementing abstractions of what a sparse array is and what operations can be done that leverage this underlying core API, ii) finishing the co-iteration algorithm to account for non-unique and non-ordered levels and iii) begin work on the actual code-generation algorithm that leverages the merge lattice.

Integrate a new architectural component into Meshery: a workflow engine. This project involves shifting Meshery off of bitcask and off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.

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.

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 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>LLVM includes binary utilities equivalent to GNU binutils. Basic functionalities are done but there are incomplete ones such as Mach-O support. This project aims to support those missing functionalities and improve usability for those who crave for an alternative to GNU binutils.</p> <p>The goal of proposal is twofold:</p> <ul> <li>llvm-objcopy: Improve Mach-O support</li> <li>llvm-objdump: More human-friendly disassembly</li> </ul>

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>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>In this project we will look at loop transformation heuristics, such as the unroll factor.</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>

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

Three-way comparisons are present in many high-level programming languages, such as C++ with its spaceship (<=>) comparison operator or Rust via the Ord/PartialOrd traits. Currently, there is no way to express such a comparison using a single operation in LLVM, which means that instead frontends can emit many different sequences of instructions instead. LLVM does not necessarily produce the most optimal machine code for each of such sequences. The goal of this project is to add an instrinsic to the LLVM IR language that would perform this comparison for integers, which can then be used by the frontends and which can have all the optimizations tailored to it, allowing more optimal machine code to be produced.

<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>The performance of the code generated for the GPU heavily depends on runtime parameters such as the number of thread blocks and threads per thread block. For this reason, a proper choice of such parameters based on both the IR information and runtime information can give a tangible improvement of the performance of the generated code. In this project, we will explore the ML-based approach to this problem which uses machine learning models for making a decision on the runtime parameter values given the IR and runtime features.</p>

Current memory semantics of the LLVM-IR use undef when dereferencing an uninitialized memory location. This prevents optimizations within scalar replacement of aggregates (SROA) and memory to register (mem2reg) from being performed. The solution is to convert uninitialized memory location loads to poison. This proposal outlines implementation methodologies for bit-field loading and storing, replace phi-undef with phi-poison for conditional stores in SROA and mem2reg, and the automatic conversion of previous LLVM-bitcode for compliance with the new memory load semantics. This work will increase use of poison semantics further contributing to the eventual deprecation of undef. Once poison based memory semantics are implemented InstSimplify, SSAUpdater, and other optimizations can be refactored.

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

-fbounds-safety is a C language extension designed to prevent out-of-bounds memory accesses. Currently, upstream Clang provides partial support for some annotations such as counted_by. The proposal aims to extend the scope of the currently supported annotations and upstream missing ones.

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