Explore Projects

This project aims to give LLVM-clang the ability to generate ExtractAPI symbol graph files as a side-effect of a regular compilation job. This can enable using the symbol graph format as a lightweight alternative to do code intelligence offline and outside of an interactive context.

This project is based on the proposed project (Learning Loop Transformation Policies) by the mentors Johannes Doerfert, Mircea Trofin. This project would like to experiment on how the compiler may learn for improvements by observing from the back-end. We can try it on RISC-V, an open instruction set architecture.

<p>Electronic Delay Storage Automatic Calculator (EDSAC) is a first generation British computer commissioned in 1949. It was built by Maurice Wilkes and his team at the University of Cambridge Mathematical Laboratory. EDSAC is the world’s first stored-program computer.</p> <p>The project’s goal is to reimagine the EDSAC on modern hardware, with the ultimate objective to make the historic computer accessible to and reproducible by a new generation of computer architects and engineers. Investigating the evolution of computing techniques gives architects and engineers context to modern concepts of computer architecture, organisation and design.</p> <p>The historic computer, complete with all its subsystems, will be replicated on an FPGA, using Verilog HDL, capable of accepting and executing all EDSAC Orders. To emulate the ancient I/O, various “I/O flavours” will be designed to interface with the FPGA board, via a standardised communication protocol. Users can choose, extend and even add new I/O flavours. An assembler utility will be built in Python, which users can utilise to debug and build their code for EDSAC, which can be then loaded onto the FPGA for execution.</p>

<p>Polly uses custom C++ bindings for isl (Integer Set Library) which is a library written in C. I aim to replace at least partially the usage of these custom bindings in favor of the official isl ones. 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.</p>

<p>MLIR is a novel compiler infrastructure that enables multi-level abstraction and therefore enhances reusability and extensibility. The core concept that allows to extend MLIR is a dialect. This project focuses on the implementation of SPIR-V to LLVM IR dialect conversion within MLIR. Some benefits of this conversion path include generating CPU machine code for SPIR-V and JITing SPIR-V.</p>

<p>LLVM uses a Jenkins instance and Jenkins-Debian-Glue to build LLVM, Clang, clang extra tools, compiler-rt, polly, LLDB and LLD packages for the stable, stabilization and development branches. These Debian and Ubuntu repositories are hosted on apt[dot]llvm[dot]org. This GSoC I plan to deploy an instance of Open Build Service (OBS) and port the various scripts and packages to this platform such that it don't change the present user interaction.</p>

<p>A newly added idea of LoopNest pass enables to handle a loop nest efficiently, unlike function pass or loop pass.</p> <p>The goals of this project are:</p> <ol> <li>Utilizing LoopNest pass for some existing passes intended to run on loop nest</li> <li>Collecting data on the utilized passes (e.g. compiling time)</li> <li>Improving the current implementation of LoopNest (pass) itself as necessary</li> </ol>

<p>The Clang Static Analyzer is used to find bugs in the program by analyzing source code without compiling and executing. It uses symbolic computations to find the defects. The Clang Static Analyzer already has a checker to find the null pointer dereference in code, however it is not sufficient for complicated cases such as C++ smart pointers or optionals. By explicitly teaching the C++ standard class behaviors we can make the Analyzer to find more bugs related to modern C++ code.</p>

Rust is a popular system programming language that relies on LLVM for its compilation. Rust has a variety of features and paradigms and states “Zero cost abstractions” as a core value, and a variety of optimization failure issues have been discovered and reported by the language community. By addressing these issues, we can not only improve the performance of Rust binaries but also help LLVM develop more robust optimization pipelines. The goal of this project is to analyze and fix the optimization issues, especially on InstCombine/InstSimplify, SimplifyCFG, MemCpyOptimizer, and Vectorizer-related pass.

Value numbering is a key compiler optimization. Currently, LLVM’s optimizer offers two implementations, GVN and NewGVN, neither of which is entirely satisfactory. While GVN suffers from performance issues and lacks extensibility, NewGVN, although potentially superior, remains unstable for production use. This project aims to address these shortcomings by focusing on improving NewGVN. By enhancing its performance and optimization power, our goal is to surpass GVN and establish NewGVN as the default value numbering implementation in LLVM’s optimization pipeline.

The LLVM libc project was designed as an alternative to glibc that aims to be modular, configurable, and sanitizer-friendly. Currently, LLVM libc is being ported to Nvidia and AMD GPUs to give libc functionality to code running on GPUs. As of March 2024, programs can use GPU libc in offloading languages (CUDA, OpenMP) or through direct compilation and linking with the libc library. This project aims to provide accurate benchmarking features for libc for GPUs (Both Nvidia and AMD) to find a baseline timing for libc functions running on the GPU.

<p>Mapping between the natural language text of a contract and attempting to classify data types such as monetary amounts, dates and legal specific terms such as agreement parties, etc. into cicero variables from the existing model library.</p> <p>Therefore, users can export a smart legal contract by natural language contract text.</p> <h3>How to do it?</h3> <h4>A. Data Mapping using NER by RoBERTa.</h4> <p>Build a scaleable NER model by Adapter Transformers based on RoBERTa.</p> <p>The model also have Active Learning pipelines. User can define their own custom data type label then upload data and train the Adapter. By doing so, the model will recognize their new tag.</p> <h4>B. Suggest about templates by Classification Model</h4> <p>When users first upload their natural language contract, NLP model will tell them which smart legal contract template is suitable. So users can use or fine-tune the contract easily.</p> <h4>C. Identification contract variables by BERT QA Model</h4> <p>Input contract text, NLP model will suggest user which they need to put onto smart legal contract's variables.</p> <h4>D. API backend.</h4> <p>User can call the NLP model by API. Provide a Swagger UI Documents and plenty of examples.</p> <h3>For more detail, please <a href="https://github.com/accordproject/labs-cicero-classify" target="_blank">go to README in the GitHub Repo</a></h3>

MLIR’s Presburger Library, FPL, provides mathematical abstractions for polyhedral compilation and analysis. When many set operations are performed in sequence, the constraints can become very large, and the goal of the project is to find a balance between the additional time costs and the appropriate constraint system size. To achieve this, this project will implement a benchmark tool to measure the running time and constraint system size, and a series of heuristic simplifications to reduce the constraint system size. Ultimately, the benchmark tool will be used to choose the appropriate simplifications.

For an example like: template<class T> struct Foo { using type = T; }; using Bar = int; Foo<Bar>::type baz; In clang, baz’s type will not desugar to Bar, as the member access in Foo<Bar>::type will go directly for the canonical type of the template instantiation. This will cause any diagnostics printed from this type to miss this information. If there were an attribute attached to the Bar typedef, such as alignment, this would be lost on the baz declaration. In this proposal, we want to lift this restriction by implementing the missing functionality in clang.

<p>It is common for compilers, and LLVM in particular, to transform calls to memcpy or memmove to a number of integer loads and stores of the corresponding bit width. After, load and store instructions can be optimised further. However, semantics of memcpy and memmove specify that the memory is copied as-is in bytes, and LLVM does not have a type to represent the handle to the raw memory (like unsigned char or std::byte in C/C++). This leads to incorrect transformations and miscompilations.</p> <p>This project aims at introducing a new byte type to LLVM IR to fix miscompilation issues and to make the semantics of type punning in LLVM consistent.</p>

<p>Polly can perform classical loop transformations, exploit OpenMP level parallelism, expose SIMDization opportunities. However, due to the lack of a machine-specific performance model and missing optimizations, these transformations sometimes lead to compile and execution time regressions, and the generated code is at least one order of magnitude off in comparison to the corresponding vendor implementations. The goal of the project is to reduce such influence through implementation of optimizations aimed to produce code compatible with the best implementations of BLAS and an attempt to avoid vectorization of loops, when it is not profitable for the target architecture. It could be a step in transformation of Polly into an optimization pass used in standard -O3 optimizations.</p>

<p>Maintaining consistency while manual reference counting is very difficult. Languages like Java, C#, Go and other scripting languages employ garbage collection which automatically performs memory management. On the other hand, there are certain libraries like ISL (Integer Set Library) which use memory annotations in function declarations to declare what happens to an object’s ownership, thereby specifying the responsibility of releasing it as well. However, improper memory management in ISL leads to invocations of runtime errors. Hence, my proposal is to employ a robust static analyzer in clang which raises warnings in case there is a possibility of a memory leak, double free, etc.</p>

Within this project, I aim to create a new ML model based on the already existing MLGO work in register allocation to further enhance the performance of the ML-enabled live range eviction heuristic. I plan on utilizing graph based features, particularly a program dependence graph and the live range incidence graph to improve performance over the currently engineered features. Starting off, graph data will be exposed to MlRegAllocEvictAdvisor (first deliverable), then an initial model will be trained in the same manner as the previous ML model for live range eviction (second deliverable), and finally the model will be fine tuned and optimized for use in production (third deliverable).

This proposal aims to refine and expand the testing infrastructure in the LLVM C library to help users balance speed and accuracy of math functions on GPUs. On the performance side, the proposal intends to improve the existing benchmarks that compare the LLVM C library’s implementations to vendor libraries, and add new math functions to the test suite. On the accuracy side, the proposal seeks to develop an exhaustive (brute force) test suite that verifies conformance to error tolerances, such as those defined in the OpenCL standard. The resulting deliverables include an enhanced performance test suite, a new accuracy test suite, and a consolidated report of performance and accuracy results for the covered functions.

The primary vision is to enhance clang’s UBSan trap mode by tackling the three main goals, which include adding a warning to the -fsanitize-trap=undefined, teaching clang to emit the UBSan trap reasons, and confirm LLDB is able to recognize the UBSan trap reasons. The deliverables are: implementing a check to properly emit a warning for when -fsanitize-trap=undefined is passed alone, creating an enumeration to list out all possible UBSan trap reasons, adding functionality to encode those trap reasons, and display the trap reasons to the user with LLDB. If time permits, work can be conducted on emitting more precise trap reasons from information that may be available within the compiler.

NewGVN was introduced to LLVM to cope with the limitations of the old GVN. It hasn't, however, seen widespread adoption, due to its bugs and missing features in relation to the old GVN. One source of issues with NewGVN is its handling of undefined behavior (UB). We are either too permissive, which can lead to correction issues, or we try to disable it, which makes us lose potential optimizations, while also not making it completely correct. Major steps: 1. Compile test cases showing NewGVN's failure to handle UB 2. Write pseudocode for NewGVN 3. Fix pseudocode 4. Implement changes Expected result: An improved version of NewGVN with better handling of UB and more awareness of its overall limitations.

This project aims to improve the accuracy of compiler-generated remarks and analysis reports by including corresponding source-level expressions in addition to line and column numbers. The project will leverage the intrinsic functions used by LLVM to map LLVM program objects to source-level expressions, and propose solutions to generate source expressions when the existing information is insufficient. The focus will be on optimizing memory accesses in a program by reporting memory access dependences that inhibit vectorization. The expected result is an interface that takes an LLVM value and returns the equivalent source-level expression, with a specific emphasis on mapping addresses used in load/store instructions to source-level memory references.

Enzyme plugin project aims to automatically find derivatives of LLVM IR which is pretty helpful for ML related works.Enzyme code base still uses the legacy pass manager and 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 user may not understand why they get linker errors. Currently they must add a flag to specify the old pass manager. In this project I will integrate the new pass manager in the enzyme code thus making Enzyme callable by the new pass manager. The behavior of the plugin to the legacy pass manager will stay the same .