Explore Projects

<p>This project is about improving LLVM backend for chapel compiler. Improvements consist of improving loop vectorization by adding proper metadata and changing loop compilation, adding type-based alias analysis metadata, adding notations when there is load from const memory, experimenting with aliasing algorithms, adding polly optimizer and extending support for wide pointers. Main goal of the project is to improve loop vectorization.</p>

<p>The <a href="https://docs.google.com/document/d/1dOK9FYKf2egZcYqrR3rdtF8o2ykTdVxwuuwZcrs5lwQ/edit#heading=h.b4gt1ulsb82o" target="_blank">Alive for SIL</a> project aims to build a tool that will find errors in optimizations performed by the Swift compiler.</p> <p><a href="https://swift.org/swift-compiler/#compiler-architecture" target="_blank">SIL</a> (a.k.a. Swift Intermediate Language) is an IR (a.k.a. intermediate representation) used within the Swift compiler between the Swift AST and LLVM IR. SIL enables the Swift compiler to perform Swift-specific optimizations.</p> <p><a href="https://sf.snu.ac.kr/publications/alive2.pdf" target="_blank">Alive</a> is a tool that formally verifies the correctness of optimizations performed on LLVM IR and produces counterexamples when such optimizations are incorrect. For example, if an optimization accidentally adds undefined behavior into a program, then Alive2 would be able to find this error and produce an example that exposes the undefined behavior.</p> <p>This project aims to extend Alive to verify the correctness of optimizations performed on SIL.</p>

Support for differentiable Faust algorithms is currently provided by an external JAX backend. The aim of this project is to add automatic differentiation capabilities to the Faust compiler with a view to enabling a variety of machine learning approaches to digital audio synthesis and signal processing directly within the Faust language.

<p>TACO or Tensor Algebra Compiler is a C++ library that generates efficient code for tensor algebra kernels. It also has a Python binding around it called Pytaco that makes TACO available in Python. However, Pytaco is not ndarray compatible yet. This projects intends to wrap up Pytaco along with PyData/Sparse in an ndarray compatible API. The new API will be called ndsparse. Ndsparse will eventually replace scipy.sparse as the de-facto sparse array implementation in the PyData ecosystem.</p>

This project aims to optimize the Pharo compiler by implementing bytecode level optimization within its DRUID-based optmizing compiler. By applying inlining, which involves replacing method calls with the actual code of the methods, the number of method calls in the virtual machine will be reduced, thus enhancing execution speed. The project will extend DRUID by supporting complex cases like block closures, improving the type system, and conducting thorough performance benchmarking. Deliverables will include the implementation of bytecode-level inlining, the enhancement of the type inference system, testing and validating the new compiler, and performance analysis.

<p>LLVM automatically derives facts that are only used while the respective translation unit, or LLVM module, is processed (i.e. constant function, error-throwing, etc). This is true both in standard compilation but also link-time-optimization (LTO) in which the module is (partially) merged with others in the same project at link time. LTO is able to take advantage of this to optimize functions calls to outside the translation unit. Code compiled without LTO for all of its dependencies, however, does not have this information and therefore is unable to perform such optimizations. To remedy this issue, one might propose always compiling programs with LTO enabled. This doesn’t solve the problem for two reasons of practicality: LTO comes with a nontrivial compile-time investment; and many libraries upon which a program could depend, do not ship with LTO information, simply headers and binaries. In this project, we propose solving the problem by generating annotated versions of the source code that also include this derived information. Such an approach has the benefits of both worlds: allowing optimizations previously limited to LTO without running LTO and only providing headers.</p>

This project implements the compiler infrastructure—including missing intrinsics and lang items—required to compile Rust’s alloc crate in GCC Rust (gccrs). The work focuses on bridging architectural gaps and ensuring alloc is ready for integration once core support is finalized. Deliverables include core heap-related functionality, regression tests, and documentation of the resolved compiler limitations.

<p>I will be working on building sci-fi-like 2D and 3D interfaces inspired by the “<em>Guardians of the Galaxy</em>” movie and provide physics engine integration.</p> <p>My objective is to add more futuristic widgets and make UI elements more interactive without hampering the performance. Apart from the UI, I will be also working on integrating a Physics Engine(<em>PyBullet</em>) to build realistic simulations that use the engine to simulate physics (e.g. collisions) and FURY to do the visualization.</p>

Clang includes libInterpreter, a framework for incrementally JIT compiling and executing C++ code. The goal of the project is to port this to WebAssembly and run inside a Javascript engine in a browser. This would involve modification to libInterpreter to run in WASM and produce WASM JIT code. These separate WASM modules need to be linked together and executed in the JS engine. If possible, the final goal is to integrate this with JupyterLite, a version of Jupyter that runs WASM kernels entirely on the client side.

Many C++ standard library traits are often implemented using template metaprogramming, which can result in worse compilation performance due to expensive instantiations of multiple class templates. The most likely way to address the costly instantiations is to define compiler built-in traits and get library traits to dispatch to these built-ins. It is also essential to conduct thorough benchmarking and compare the existing implementations with built-in traits, as there may be some library traits that are already optimal or non-built-in approaches that outperform built-ins. Thus, the main goal of this project is to optimize the standard library traits by incorporating built-ins and investigating alternative approaches, with the aim of enhancing the compilation performance.

<p>The goal is to build a <strong>parser generator</strong> on top of the library <em>LPegLabel</em> that will automatically support error recovery and (optionally) white spaces around lexical symbols and terminal symbols. We are going to use a conservative algorithm for error labels insertion, hence avoiding insertion on wrong places and no manual intervention from the programmer is needed. If there is enough time, in the end we will improve the number of insertions using information about unique syntactical non-terminal symbols and unique paths to a lexical symbol. During the coding period, some parsers will be generated with the tool as tests and as examples.</p>

MCS uses interepreted execution to calculate SQL expressions results. Here is an example of a SQL expression 'table1.col1 + FLOOR(table2.col1)'. Given that table1.col1 is DECIMAL and table2.col1 is DOUBLE there is a number of conditions that drives the calculation of this relatively simple example in runtime. Given that SQL types and expression tree are known before the query begins it is possible to replace interpretation with JIT to produce specialized compiled bytecode that is: small has no or almost no branches optimized for the specific platform it is run at This is a research mostly project which goal is to produce a set of microbenchmarks that: leverages any JIT compiler available, e.g. LLVM, MIR demonstrates a negative and positive effects of using JIT

As the LLVM Flang frontend matures, a significant gap has emerged between compilation and diagnostic capabilities. Currently, LLDB does not provide native debugging support for Fortran. This project aims to address that gap by building the essential foundation for native Fortran debugging. The goal is to deliver a functional debugging stack that allows users to: Inspect Variables: Support for scalar variables, function arguments, and return values. Data Structures: Inspection of static arrays, character strings, and derived types. Visibility: Implementation of module and global variable lookups. Expression Evaluation: Enabling basic arithmetic and variable inspection via the print command. To achieve this, a new Fortran TypeSystem, a dedicated Language Plugin, and a DWARFASTParser to interpret and traverse Fortran-specific DWARF metadata are needed.

Most of the day to day tests in LLVM are regression tests executed by Lit, structured as source code or IR to be passed to some binary, rather than test code directly calling the code to be tested. This has many advantages but can make it difficult to predict which code path is executed when the compiler is invoked with a certain test input, especially for edge cases where error handling is involved. The goal of this project is to help developers create good test coverage for their patch and enable reviewers to verify that they have done so. To accomplish this we would like to introduce a tool that can be fed a patch as input, add coverage instrumentation for the affected source files, runs Lit tests, and records which test cases cause each counter to be executed. For each counter we can then report the number of test cases executing the counter, but perhaps more importantly we can also report the number of test cases executing the counter that are also changed in some way by the patch, since a modified line that results in the same test results isn’t properly tested, unless it’s intended to be a non-functional change.

In Just-In-Time compilers we often choose a low optimization level to minimize compile time and improve launch times and latencies, however some functions (which we call hot functions) are used very frequently and for these functions it is worth optimizing more heavily. In general hot functions can only be identified at runtime (different inputs will cause different functions to become hot), so the aim of the reoptimization project is to build infrastructure to (1) detect hot functions at runtime and (2) compile them a second time at a higher optimization level, hence the name "re-optimization". There are many possible approaches to both parts of this problem. E.g. hot functions could be identified by sampling, or using existing profiling infrastructure, or by implementing custom instrumentation. Reoptimization could be applied to whole functions, or outlining could be used to enable optimization of portions of functions. Re-entry into the JIT infrastructure from JIT’d code might be implemented on top of existing lazy compilation, or via a custom path. Whatever design is adopted, the goal is that the infrastructure should be generic so that it can be used by other LLVM API clients, and should support out-of-process JIT-compilation (so some of the solution will be implemented in the ORC runtime).

Upgrade the Go reflection schemas in terraform-plugin-framework to detect schema misconfigurations at compile time.

<p>WildFly Elytron is a new security framework developed by WildFly to provide a single unified security framework across whole of the application server which replaced the pre existing Java Authentication and Authorization Service (JAAS) which used to be the standard Pluggable Authentication Module (PAM) information security framework. To extend Elytron’s functionality beyond the existing security realms, custom security realms can be implemented using existing Elytron’s APIs and SPIs for their usage in WildFly Elytron subsystem. Now to extend this functionality of custom development to scripting languages other than Java, Java ScriptEngine is used. During the summer as the project of GSoC under JBoss Community, I’ll be working on extending the functionality of WildFly Elytron’s implementation of custom security realms using other scripting languages.</p>

<p>LLVM Project is a collection of modular and reusable compiler and toolchain technologies. It supports various high-level languages and hardware architectures. LLVM IR is an SSA-based intermediate representation whose design helps in the easy and efficient implementation of various compiler optimizations and transformations. Alive2 is a tool that checks whether the transformation of an instruction set into another instruction set is semantically correct or not. It is a verification framework for LLVM IR, which checks whether the source and target IR are equivalent or disproves by providing a counterexample. Alive2 can reason about a wide variety of intraprocedural optimization problems, including control flow, memory, vectors, and floating-point. Alive2 has detected some fundamental issues in the LLVM-IR, which lead to mis-compilation and unsound optimizations. In this project, I propose to solve some of these issues in the LLVM IR by making some changes to the LLVM compiler infrastructure code.</p>

This project proposes building jws diag, a read only diagnostic CLI for JBoss Web Server that helps operators and SREs to inspect runtime and configuration state more easily. The tool will provide concise installation and deployment summaries, effective connector TLS and proxy configuration reporting, validation checks for common misconfigurations, structured JSON output, and realistic test coverage for troubleshooting and automation use cases.

Clang, part of LLVM, supports multiple languages and functions as a library, fostering a compiler-assisted ecosystem. Its accessible codebase and LLVM's JIT advancements enable innovative C++ processing methods, though challenges like incremental compilation and compile/link-time optimizations persist. Incremental compilation processes code in segments, building translation units and enabling efficient interpreters. Clang-Repl, using Orcv2 JIT within the same process, exemplifies this concept but faces limitations on resource-constrained devices and risks process-wide crashes on user code failure. This project aims to transition Clang-Repl from an in-process to an out-of-process execution model to address: 1. **Resource Constraints**: The current model requires substantial resources, limiting use on devices like Arduino Due. 2. **Crash Resilience**: In-process crashes can bring down the entire Clang-Repl process, affecting stability and user experience.

This proposal is based on the LLVM project for GSoC 2026 with the same title, from Tue Ly, Nicolas Celik and Krishna Pandey. Discourse: https://discourse.llvm.org/t/gsoc-2026-libc-enable-float80-and-float128-math-support-on-unsupported-targets-for-llvm-libc/89647. Float80 (x87 80-bit extended precision) and Float128 (IEEE 754 binary128 quad precision) are high-precision floating-point formats critical for correctly rounded math implementations. However, not all compilers or architectures support these types natively which prevents LLVM libc from building and testing its high-precision math routines on these platforms. The goal of this project is to implement software support for these types in LLVM libc in a compiler and architecture agnostic way. Deliverables: - Implement float80 and float128 in a compiler and architecture agnostic way. Implement generic basic arithmetic operations that work on all supported architectures. - Demonstrate compiling and passing tests on unsupported targets (float80 on Mac ARM64, float128 on MSVC).

Inspired by the pMix and Amati projects, this plugin will be built using the JUCE framework for the interface and libFaust with LLVM and interpreter backend API to compile Faust code. The user will be able to write Faust code in any VST-aware host and can be saved or recompiled on the fly. There are six components to the plugin, the editor, the console, a section for editing the parameters, a block diagram displaying the DSP, a preference page to change the settings, and a keyboard section where the user can enter MIDI inputs. The plugin will also support polyphonic Faust DSP objects, and the parameter inputs will be created depending on Faust code. Amati project is currently used as a starting point for the project, so it will use much of the existing code. However, changes might be made to them if needed.

ClangIR is the newest attempt to tackle the lack of a higher-level intermediate representation for C++. Said representation would greatly benefit the community by enabling a myriad of passes that are either impossible or too complex to execute in LLVM IR, benefiting thousands of developers and legacy code. Ensuring ClangIR's success, however, requires coverage, correctness, performance, and an acceptable build time overhead. This proposal aims to increment the ClangIR compiler to compile part of the LLVM’s SingleSource test suite, further advancing its development. This includes but is not limited to, implementing missing AST visitors, operations/instructions, types, and testing. After sufficient implementations, it should be possible to use the SingleSource programs to analyze the compilation through ClangIR, evaluating its trade-offs against the traditional lowering process.