Explore Projects

<p>Dominance relationship is used widely in many compiler analyses and optimizations. The current API provided by LLVM to update the dominator tree and the post dominator tree is fragmented and different functions using these data structures have to decide how to perform incremental updates.</p> <p>The aim of this project is:</p> <ul> <li>The API to update the dominator tree and the post dominator tree using different strategies (lazily/eagerly) is fragmented. Therefore, a single class for abstracting away the tree update strategies and which trees are actually being updated need to be developed.</li> <li>By implementing a single updater class, performing faster incremental updates will become possible. First, we can convert functions to update the data structure lazily. Second, we can use the updated dominator tree to prune unnecessary updates to the post dominator tree.</li> </ul>

The Clang Static Analyzer (CSA) can find a wide range of temporal memory errors such as use-after-free and dangling references. Some of its checkers, like cplusplus.InnerPointer, rely on hardcoded knowledge about the behavior of specific APIs. The Clang community has introduced lifetime annotations: [[clang::lifetimebound]] and [[clang::lifetime_capture_by(X)]] that let developers express lifetime relationships directly on their declarations and -Wlifetime-safety makes use of them. However, in partially annotated code, a single missing annotation is enough to prevent -Wlifetime-safety from finding the bug. The CSA can help in these situations by inlining the unannotated function. In my proposed project, I intend to implement a new standalone checker that reads lifetime annotations and tracks the resulting dependencies along different execution paths, using them as a fallback when the analyzer cannot inline a function body. The expected result is that the CSA detects lifetime bugs in both annotated and partially annotated code that it currently cannot catch, complementing the coverage provided by -Wlifetime-safety.

<p>Given the increasing number of use cases for massively parallel devices (GPUs), solving the problems they bring have become an important research field. One of the main problems that needs to be solved is the long time (latency) that it takes to move data from the computer’s main memory to the device’s memory. Therefore, using the LLVM compiler infrastructure, the proposed solution consists of adding a new functionality to the current OpenMP interprocedural optimization pass, OpenMPOpt, such that the OpenMP runtime calls that involve host to device memory transfers are split into “issue” and “wait” functions. The “issue” function will contain the code necessary to transfer the data from the host to the device in an asynchronous manner, returning a handle in which the “wait” function will wait for completion. The “issue” and “wait” functions will be moved upwards and downwards respectively, until it is illegal to do so. Doing this, the instructions between the “issue” and the “wait” can be executed, while separately doing the data transfer to the device, hence, reducing the time the process is blocked waiting for the transfer to finish.</p>

<p>TensorFlow is a popular machine learning and deep learning framework developed by Google. Despite its recent launch in late 2015, it has been widely adopted both in industry and academia. The TensorFlow community recently (in Jan ’17) open sourced a JIT Compiler for linear algebra computations (XLA) to improve speed of execution and reduce memory usage of the program.</p> <p>The LLVM and Polly Labs community has developed an optimization tool, Polly, that works on Polyhedral representations of programs, performing automatic parallelization and data locality optimizations. Polly directly extracts this polyhedral representation of the program and then performs a number of loop optimizations, including tiling and vectorization.</p> <p>The problem statement I am proposing is, to enable Polly's optimizations for XLA. It is well understood that Polly's optimizations work especially well on programs involving deeply nested array update codes like stencils, dense linear algebra kernels, etc, and hence, have applicability in a machine learning library like TensorFlow.</p>

Clang-Doc is LLVM's modern C/C++ documentation generator built on the compiler AST rather than heuristic text parsing. A key blocker to its adoption is the absence of Markdown support inside documentation comments. Fenced code blocks, pipe tables, and lists currently pass through to output generators as raw text, making generated documentation unreadable for any project that uses Markdown in its comment workflow, which includes LLVM itself. This project implements a standalone Markdown parsing library that takes text and returns typed data structures, with no knowledge of comments or Clang internals. Clang-Doc is the immediate consumer, but the library is usable by any LLVM tool. It follows the same pattern as the Mustache library from GSoC 2024, with no third-party dependencies. Deliverables include the full library, Clang-Doc integration, updated HTML and Markdown generators, end-to-end lit/FileCheck tests, a libFuzzer harness, and an LLVM blog post. Stretch goal: Clang AST support for Doxygen group comments, flagged by mentors as particularly valuable.

MLIR already makes allocation and deallocation structure explicit after bufferization and the ownership-based deallocation pipeline, but it still lacks an upstream static memory planner that can analyze buffer lifetimes and safely reuse memory for well-structured workloads. This is especially valuable for structured ML, HPC, and accelerator-oriented compilation flows where dynamic allocation is expensive or undesirable. I propose to build this in two incremental steps. First, I will implement an analysis pass that identifies eligible memref.alloc / memref.dealloc patterns, performs alias-aware lifetime analysis, computes planning metadata such as size and alignment, and reports reusable candidates and skip reasons. Second, I will build a conservative rewrite pass that rewrites eligible dynamic allocations into memref.subview-based slices of one or more statically allocated arena memrefs for legality-gated v1 cases. The main deliverables are: an upstream analysis pass for static memory planning, a conservative v1 rewrite pass for same-block structured cases, memory-space-aware planning support, strong lit/FileCheck coverage, documentation of supported and unsupported cases, and an incremental PR series that is realistic to review and land upstream.

Optimizing code for heterogeneous hardware like GPUs requires specialized approaches. While LLVM/Clang supports various GPU programming interfaces, LLVM IR hinders effective analysis for GPU code with its SIMT model. Clang's mid-level IR (ClangIR) based on MLIR is better suited to capture this information from source code. This project proposes adding basic OpenCL C support to ClangIR. Challenges and Solutions: 1. Code Generation Paradigm Shift: CodeGen and Lowering (ClangIR's compilation passes) employ distinct coding paradigms due to their underlying infrastructure (AST reflection vs. MLIR Pass Rewriter). Migrating existing CodeGen code to the Lowering framework could be complex. We will actively debate the trade-off between optimization potential and implementation complexity to propose and execute well-designed, achievable plans. 2. Scattered OpenCL Support Code: Current OpenCL support code is dispersed throughout the codebase, hindering development quality control. Strategies will be developed to address this issue, such as extracting key information from flags like getLangOpts().OpenCL and getOpenCLRuntime(), or implementing systematic code searches to consolidate functionalities and address issues in a structured manner. The final deliverables of this project include a) A set of testcases that combines unit tests with integration tests b) An AST Consumer for OpenCL C (extension of CIRGen) c) A set of MLIR Passes for properly generating SPIR Kernels d) A functional and performance test report (optional) e) Detailed development documentation for all the above parts

Pharo provides an immersive and interactive development environment with powerful refactoring tools. However, its current refactoring workflows can be fragmented, rely on frequent pop-ups, and offer limited feedback, making them less user-friendly. This project aims to improve the usability and interactivity of Pharo’s refactoring tools, with a focus on rename operations. To achieve this, the project will develop a flexible driver and preview infrastructure that supports safe experimentation, introduce live name editing with immediate validation, and enhance the visualization of changes through a hierarchical tree structure. The expected outcomes include a streamlined refactoring workflow, a clear hierarchical preview of all changes, real-time validation of user input, and a more intuitive and interactive user experience that helps developers better understand and manage code transformations.

<p>The main goal of this project is to provide a new back-end for TACO, that generates LLVM bytecode instead of C code, using the LLVM C++ API to do it. The main benefits of outputting LLVM IR are enabling optimizations at the LLVM IR level and to target any machine code available in the LLVM framework, including NVPTX.</p>

<p>Knative can autoscale applications but currently, it doesn’t support GraphQL servers with subscriptions. GraphQL subscriptions currently use WebSockets. The server maintains a pool of connected clients. If more servers are added, how does a server get notified about mutations made on other servers. Simply scaling your GraphQL server is not enough. This project aims to use Kafka, Debezium and Offix to extend subscription support to Knative and Add Offline Capabilities.</p>

<p>Implement a new Web Assembly compiler backend for Accord Project's smart contract language (Ergo). This will allow Accord Project users to deploy their contracts to any WASM platform or allow any WASM user to call Accord Project templates.</p>

This project aims to extend SourceKit LSP to add DocC Language features like go-to-definition and diagnostic support for missing or broken symbol links. It also enhances the documentation preview by making it interactive with clickable symbol links and web URLs, along with syntax highlighting for .tutorial and .md files.

The project aims to incorporate AI features into Template Playground to facilitate the creation of Templates and Concerto models. The ability to generate Accord Project Templates from user submitted text will be implemented. Users will be able to chat with their chosen LLM and get an understanding of how the whole ecosystem of Accord Project works in tandem to produce agreements. The editors in Template Playground will be enhanced with the ability of providing AI powered inline suggestions.

This proposal describes how we can implement Lexical scopes library for swift-syntax. The library would describe what declarations are available in what scopes, would enable looking up declarations of particular references as well as finding what scopes that keywords refer to. The functionality would be beneficial especially from the compiler and IDE perspective. This approach focuses on creating a tree structure under a common protocol that would enable a bottom-up recursive reference lookup. In order to directly access scope information, AST nodes would be extended with additional scope-related properties.

The objective of this project is to provide alias support in concerto language . For example import statement like "import {document as d} from Library" to be supported by the end of this project. This would allow us to import two models with same name in a single file by aliasing them to different names which is currently not supported in the language. Doing this would require changes in both the concerto-parser and concerto-runtime . The project requires compiler design and programming language knowledge. The stack used in project is NodeJs and written in typescript. The concerto-parse is written in PEGJS.

The Platform Level Interrupt Controller (PLIC) is the de facto interrupt controller in RISC-V systems. However, the specification has intrinsic limitations regarding scalability and feature richness, e.g., it lacks support for Message Signal Interrupts (MSI) and virtualization. The RISC-V Advanced Interrupt Architecture (AIA) is the new reference specification for interrupt handling. RISC-V International has just ratified the AIA specification. This project aims to integrate an (in-house) open-source AIA IP into the OpenPiton+Ariane platform and conduct an in-depth evaluation of the performance and suitability for general-purpose, multithreaded, manycore processors.

<p>Swift supports multiple levels of optimizations per single module. This project aims to achieve LTO support for Swift at LLVM level and at Swift’s intermediate representation level to do more aggressive optimization across modules.</p> <p>This proposal suggests language-agnostic LTO support and linker plugin implementation for Swift specific LTO.</p> <p>The linker plugin will be able to accept serialized Swift Intermediate Language (SIB) files for multiple modules and performs cross-module optimization passes (e.g. Dead Code Elimination, Inlining).</p> <p>As a result, it’s expected to achieve significant binary size reduction and runtime performance improvements.</p>

This project aims to bring Ariane+OpenPiton closer to RISC-V RVA23 compliance by adding support for the Svadu extension. By enabling hardware-managed Accessed and Dirty bit updates, Svadu eliminates unnecessary software-managed page faults and improves virtual-memory efficiency. I will implement the required changes across the PTW, TLBs, LSU-side update path, and a new hardware unit, Page Table Entry Updating Engine (PUE), while building a robust verification framework based on Spike, Verilator, and handwritten assembly tests. In addition to a complete Svadu implementation, the project will deliver evaluation results, reusable verification infrastructure, and upstream-ready contributions for future RISC-V MMU-related RVA23/RVB23 extensions.

Millions of lines of open-source Verilog exist but remain verbose and hard to maintain. TL-Verilog offers a cleaner abstraction, but almost none of this codebase has been converted. This project strengthens the LLM-driven conversion pipeline in the conversion-to-TLV repository by improving error recovery, refining prompt recipes for complex Verilog patterns (FSMs, parameterized modules, arithmetic pipelines), and applying the flow to real open-source modules including RISC-V components. All conversions are formally verified using SymbiYosys and EQY, generating high-quality training data for future LLM improvement. Deliverables include a fast working failure-classification system, improved prompts.json recipes, 10+ converted and verified modules, and structured training data registered in the project repository.

DocC Render is an open-sourced project that let us visualize `.doccarchive` on the web, it renders the compiled Swift codebase documentation in a clean and standardized UI making it easier for developers to learn, review and share packages and frameworks documentation. The codebase documentation can get very large easily and right now the DocC rendered website only provides certain filter and search capabilities through the sidebar, but besides that, there's no convenient way to explore the docs. In this project we are going to design and implement the “Quick Navigation” feature into swift-docc-render, allowing users to navigate and discover documentation symbols and files easily. Similar to "Open Quickly" in Xcode and other web-based documentation sites we will let the user type and find what they are looking for through some cool capabilities including fuzzy search, quick access to recent symbols, and keyboard navigation.

<p>Open Tiled Manycore System-on-Chip (OpTiMSoC) is an open-source framework that allows one to design and prototype manycore-based platforms on FPGA devices. In its current status, OpTiMSoC offers wide support for experimenting different architectural-level configurations. However, when comes to benchmarking the prototyped platform at software-level, current runtime libraries and operating systems still have to be improved. To address this problem, the goal of this project is integrate OpenRISC Linux Port into OpTiMSoC. To do so, a new manycore configuration with a Host Tile will be designed and implemented. The Host Tile will run OpenRISC Linux and will be able to communicate with Gzll kernels running on Computing Tiles via message-passing through the Network-on-Chip (NoC). Overall, the communication infrastructure will be exported to user-level through standard UNIX file system operations.</p>

<p>LibreCores.org lists free and open source “IP Cores” on the website for the community to view and use. All listed projects are backed by a git repository. Currently, LibreCores.org websites extract the project README and LICENSE and render them on the project page, along with links to the project homepage and git repository.</p> <p>A user browsing for cores on LibreCores will be interested search for a specific category of projects to determine which projects will come under which classification. A user may want to search for a project through a list of projects. The indexing of all the IP Cores and Improving the search experience in LibreCores in terms of discoverability. The IP Cores details will be classified and indexed for making search experience better and more efficient.</p> <p>This project aims to add classification system for better categorization of a project and to implement a search engine for a better searching experience of projects on LibreCores.org.</p>

Currently, SourceKit-LSP only shows the first line of the documentation for code completion items. Furthermore, it doesn’t support the Language Server Protocol’s (LSP) signature help request which provides information about the function or subscript being completed like alternative signatures, documentation, parameter list, and parameter-specific documentation. The goal of this project is to enhance how SourceKit-LSP displays documentation for code completion items by: 1. Providing the full documentation for code completion items rather than the first line only. 2. Implementing LSP’s signature help request to provide richer guidance for completing function/subscript signatures. The implementation will require changes in SourceKit-LSP and sourcekitd in the Swift compiler codebase. This will enhance the developer experience for Swift developers using SourceKit-LSP on editors like Visual Studio Code and Neovim aligning with Swift’s vision of cross-platform support.