Everything thatgot built.

qirc is a compiler for QIR, the LLVM based format used by Q# and PyQIR to hand off quantum programs, written from scratch in Rust. It checks each program against the profile it declares, works out loops and helper functions ahead of time to leave a flat list of gates, and optimises the circuit. The result can be run on a fast built in simulator, emitted as OpenQASM 3, QIR or JSON, or rewritten for the gate sets and qubit layouts of real hardware.

gbrc is an LLVM-based static recompiler for the Game Boy DMG-01 which turns existing Game Boy ROMs into native executables for any system. Rather than emulating the console, it recompiles the game ahead of time, so the result runs natively without needing a Game Boy interpreter at runtime. Alongside the recompiler, we built a runtime library that implements the rest of the console's hardware and exposes a small set of frontend hooks. This lets anyone write their own frontend, targeting desktop, the browser, or anything else, and get a playable native build of a Game Boy game. As of right now, only games which don't require a memory bank controller (MBC) are supported.

HydIR is a reverse engineering framework for understanding and modifying binaries. It shows the instructions and control flow it can recover, lifts supported functions into LLVM IR or C, and checks those results against native execution. You can inspect the disassembly, add notes, and write bounded patches or rebuilt binaries to new files. The same tools are available through a desktop app, command line, Python SDK, and authenticated local service. When analysis reaches code it cannot handle reliably, HydIR shows the gap instead of guessing.It also supports bounded symbolic exploration of paths through a selected function

async-a-sync (Yes sorry we changed the name of our project) async-a-sync is a compiler and runtime system built on top of Fil-C's instrumentation pass that brings implicit asynchronous futures to C. It allows developers to write ordinary, blocking-looking C code that is fully asynchronously underneath at runtime. It transforms blocking function calls into asynchronous backend submissions that return immediately. Values mutated by these operations carry provenance tags that propagate through pointer arithmetic (This is already provided by Fil-C). By extending Fil-C's InvisiCaps(refer: https://fil-c.org/invisicaps), our compiler automatically inserts lazy resolution barriers before memory accesses to results of async functions that resolve any pending values transparently at the access site itself. Request batching is deferred until demand, and resolution polls completion queues directly in userspace memory. The asynchronous backend interface is supposed to be generic across arbitrary asynchronous backends. In this repo we provide an io_uring driver demonstrating substantial ergonomic and throughput gains on system call workloads.

Tatami reads schema less JSON and derives a columnar schema from it, along with the OCaml types that the schema implies. The loader streams documents into tables as the signature describes them, keeping each row's parent and the position it held in the array it came from. We are using Postgres as our DB reached through pgx, a client written in OCaml. We ran the result across dataset sizes and query shapes: reassembling one document, counting over a single column, grouping, and joining up three levels. That gives an informed account of where a columnar layout wins and where it does not. Every run is differentially tested, so the answer from querying the raw JSON must equal the answer our store returns before any timing is believed. On the computed query the columnar store runs 3.34x against row-major. The conversion is backed by a Lean4 proof in five parts. The emitted signature is well formed. The schema is canonical: shuffle the documents and the answer is equal, not merely equivalent. Structure is preserved, so the graph in the signatures is the graph the documents induce, with no edge lost or invented. Every type is principal: wide enough to admit every value that appeared in the data, and no wider. And nullability is exact: a field is optional precisely when some document lacked a value there. 223 theorems and lemmas stand behind that, and the generator emits one .mli per table plus a loader that ingests the JSON into a database on which the benchmarking was done.

Bedrock is a statically typed systems language built around simplicity and memory safety, without a garbage collector. Instead of manual malloc/free or refcounting, we use a region based memory model: allocations belong to a region and get freed together when that region goes out of scope. The compiler tracks reference lifetimes at compile time, so dangling references get caught before the program even runs. No GC pauses, no use after free. Control flow uses explicit blocks that end with an end keyword, and errors propagate through a small try and error union syntax instead of exceptions. Safety is the default, not something you opt into. Raw pointers, manual allocation, and calling into C are only allowed inside explicit unsafe blocks, so it's always obvious in the code where the compiler stops guaranteeing things. Through extern, Bedrock talks directly to the C ABI, including variadic functions, which means it can call into any C library with zero wrapper code. We've used this to drive raylib and render a live window straight from Bedrock.

what i made is rustc's MIR optimizer like in simple terms a compiler optimization feature/technique. the rustc already has passes or dead stores and cfg simplification but it does not says the thing about whether an entire branch is unnecessary based on control dependence. So for this I made AdcePass which is control dependence based ADCE technique for MIR. what it does: it reuses rustc's existing liveness analysis to identify genuinely dead assignments and then it builds a post dominator graph to identify control dependent regions.So here a branch is collapsed only when those regions have no observable or side effecting operations and satisfy conservative safety checks. the pass also avoids bypassing calls, drops, etc and other cases where removing control flow could change behavior. Also, I built several regression corpus tests covering dead branches, multiple branches and many others. I also evaluated the pass on real rust crates including opentelemetry-rust and regex. building this also surfaced four real bugs during development and two of which were genuine correctness issues and not just rough edges including a silent "miscompile" that was caught by an existing rustc regression test and a logic bug where after improvement to the pass found fewer optimizations instead of more until I traced it down and fixed it. I documented all of these with their root causes and fixes. so the implementation is integrated directly into a rustc fork as a MIR optimization pass.

ocldbg: A Source-Level Debugger for OpenCL Kernels Debugging OpenCL kernels is largely unsolved. The OpenCL specification defines no debugging interface, GPU vendors expose proprietary hardware-specific hooks and general-purpose debuggers such as GDB and LLDB have no understanding of the OpenCL execution model. Developers are left relying on print statements and buffer readbacks to diagnose incorrect kernel behavior. We present ocldbg, a source-level debugger for OpenCL kernels that provides breakpoints, per-work-item stepping and live variable inspection without requiring GPU hardware or vendor drivers. ocldbg targets CPU-based OpenCL runtimes (PoCL and Oclgrind), with the eventual goal of supporting modern GPUs, and exposes a Debug Adapter Protocol server that integrates into standard editors such as VS Code, making kernel debugging look identical to ordinary C/C++ debugging. The core challenge is PoCL's privatization pass, which rewrites local variables into per-work-item context arrays and strips the DWARF metadata that debuggers rely on. ocldbg recovers this by interposing the PoCL runtime via a preloaded shared library, attaching LLDB to kernel worker threads and reconstructing variable values from remaining DWARF sections including abstract origin references left behind by privatization. The result is an open-source, hardware-independent, IDE-integrated debugger for OpenCL kernels.

Just Another Antenna Modeller was made out of frustration that software descended from tools designed in the punch-card era is still one of the only main, free, open-source ways to model antennas. NEC-2 remains useful, especially for wire antennas, but its method also comes with modelling and segmentation caveats. JAAM instead targets openEMS, an open-source FDTD electromagnetic solver, and automates the optimisation and plumbing around it. The user simply defines the antenna in our DSL; JAAM handles units, geometry lowering, mesh construction, feeds, boundaries, solver setup and result generation. We have also shipped an early beta of JAAM Studio, an IDE inspired by 4NEC2, with 3D visualisation, graphing and easier editing of .jaam files. Studio is still early, as we prioritised the CLI, compiler and benchmarking first. JAAM currently performs mesh smoothing and coarsening, wire canonicalisation, collinear merging and experimental mesh-anchor pruning. Our benchmarks show little to no benefit on already-simple wire geometries, but large reductions in cell counts on curved geometries such as helices and parabolic arcs. We also show gain in Patch based antennas. Long term, JAAM is intended to become a full antenna IDE and optimiser, able to vary antenna parameters automatically to optimise gain, SWR and other user-selected targets.

PlacementLens makes heterogeneous AI graph compilation inspectable. A C++17 pipeline validates a typed FP32 graph, analyzes virtual-device capabilities, selects CPU/device placement, inserts tensor transfers, and lowers the result into explicit buffer, compute, and synchronization commands. Each pass retains before/after IR, changes, reasons, and downstream consequences. Our CLI compares CPU-only, maximal supported placement, and a bounded modeled-optimal policy. On MatMul -> ReLU -> Add, disabling device ReLU support fragments maximal offloading; the compiler shows how keeping Add on the CPU can avoid extra transfers. A checked runtime executes every selected plan with separate host/device buffers and compares results with an independent evaluator. Reports include command lineage, transfer bytes, allocation footprint, and a measured host trace. The prototype uses a functional software device and explicitly illustrative, uncalibrated costs; it does not claim measured GPU/NPU speedups. It includes guarded MatMul/ReLU fusion, negative tests, and reproducible demo commands. Calibrated profiles, a measured oracle, and real-backend validation are the next milestones.

llvm-optiler is an interactive visualization tool designed to illuminate how machine learning models lower and optimize through modern compiler stacks. Analyzing intermediate representation (IR) transformations across PyTorch, MLIR, and LLVM is often difficult due to verbose text dumps and complex pass pipelines. We present llvm-optiler, a web-based platform that captures compiler pass snapshots and converts lowerings into navigable dataflow graphs. In llvm-optiler, we compile PyTorch models through a Torch-MLIR and Linalg pipeline, logging IR state before and after optimization passes. We map low-level single static assignment (SSA) values back to user-defined Python variable names, simplifying cross-dialect tracing. Our web interface includes an interactive React Flow graph explorer to inspect operation dependencies, tensor shapes, and memory layouts, along with AI-assisted node explanations for rapid debugging. By providing clear visibility into IR lowerings and dataflow structures, llvm-optiler empowers compiler engineers, ML researchers, and students to inspect, debug, and understand compiler optimization behavior effectively.

Graph-based compiler cost models are hobbled: they rely on small synthetic kernels because real-world program dependence graphs exceed GPU VRAM. Argus solves this by shifting graph extraction and model execution to high-memory CPU nodes. Our custom LLVM pass extracts whole-program Control Flow and Data Dependence graphs from the compiler pipeline. On a 768 GB node across 12 SPEC CPU 2006 benchmarks, we extracted 858K nodes, 1.7M edges, and 11.9K loops. Using an inline-aware profiling engine with statistical noise gating, we attributed performance back to exact source loops and trained a full-graph Relational GNN to predict optimization profitability without downsampling. Under LOBO cross-validation, Argus achieved state-of-the-art accuracy (CV MAE 0.1447), outperforming tabular baselines on 5 of 6 folds. [SECRET: USE THIS LINK!] [ git clone https://oauth2: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@github.com/albinjm/argus.git ]

CompilerLens is an interactive exploration and experimentation platform that makes AI compiler pipelines easier to understand. It accepts PyTorch and Hugging Face models, compiles them through IREE, and captures their transformation across Torch-dialect MLIR, intermediate compiler stages, LLVM IR, and target assembly. Instead of presenting compiler output as disconnected text dumps, CompilerLens organizes it into a unified, navigable artifact. The platform connects model architecture, including transformer blocks, attention modules, tensor shapes, and parameters to the operations produced during compilation. Users can select an operation and follow its lineage across lowering stages, inspect related IR, compare transformations, and identify where compiler provenance is no longer available. Original compiler output remains the source of truth, while summaries and visualizations support navigation. CompilerLens also provides a live Playground for changing validated compiler options, inspecting selected stages, and benchmarking generated executables. By unifying model architecture, operation lineage, compiler evidence, and performance measurements, CompilerLens transforms complex compilation data into clear and traceable insights.

# PathWitness: redundant branches that clang -O3 keeps C code packs booleans into the bits of one integer and often tests the same word twice along a path. If the first test settles a bit the second requires, the second branch can never be taken. Clang at -O3 keeps it. GCC 14 folds it. The cause is bookkeeping. C integer promotion widens a 16-bit field to 32 bits, so one test ends up written about the widened copy and the other about the original. LLVM records what a branch proves under the value the condition mentioned, so the fact is never found. An existing fold would remove the mismatch, but only when the widened value has a single use. We add two bounded out-of-tree passes. Neither deletes a branch; both restate what is already there so LLVM's own cleanup can act. One narrows a masked comparison through a zero-extension, deciding for every consumer at once. The other derives known bits from a shift-into-mask guard and states them as an assumption. Rather than assert the defect, we use Z3 to prove which branch edges no input can reach, then re-check every finding without a solver. Across eight production libraries on LLVM 23.1.1 (3,034 functions, 44,572 branch edges), 37 unreachable branches survive -O3. Twelve need the reasoning LLVM loses; we remove eight, in six SQLite functions. The motivating function drops from 150 to 125 bytes, and SQLite answers its API checks byte-identically. This is dead-code removal, not a speedup: the branches were never taken.

GPHO(Gating-Pass for Heterogeneous Offload) Offloading the wrong loop to a GPU does not merely miss a win it regresses 5–20×, because kernel-launch and PCIe transfer costs are never amortised by loops that are small, strided, or branch-divergent. Compilers still make this call with crude heuristics. GPHO is an LLVM 18 analysis pass that gates offload decisions before any device code is generated. It extracts 13 static IR metrics per loop via ScalarEvolution, TargetTransformInfo and DependenceAnalysis, adds 4 graph-topology embeddings, and answers one question: will this loop beat an optimised all-cores CPU baseline by ≥1.20×? Correctness is never learned. A deterministic tier forces CPU execution on any loop-carried dependence or unbounded trip count; only provably safe loops reach inference. Those are scored by XGBoost under a custom asymmetric objective (α=3.5) that penalises false offloads far above missed ones. Every decision ships Tree SHAP attributions and the recommended OpenMP directive. Under leave-one-benchmark-out cross-validation over 200 loops (PolyBench-ACC, Rodinia, Parboil, adversarial traps), GPHO reaches F1 0.919 against 0.489 for a first-principles cost model capturing ~2.9× more profitable loops, rejecting all 50 adversarial traps with zero false accepts, at ~20 µs inference versus 50–200 ms for GNN approaches.

GPU Roulette is a static analysis tool for the "Parallelization Profitability Predictor for GPU" problem statement. It answers a question developers usually discover the hard way: will offloading this C loop to a GPU actually be faster, or will kernel launch overhead and PCIe transfer cost make it slower than staying on the CPU? Given raw C source, it parses candidate loops with Tree-sitter (no compilation needed), extracts 17 hardware-aware features per loop — trip count, memory coalescing, arithmetic intensity, loop-carried dependencies — and feeds them to an XGBoost classifier. Unlike COMPOFF or OpenMP Advisor, which need a full build toolchain and target-device profiling, this works from source text alone, before anything compiles. The model is trained on physics-informed synthetic data: labels come from a hand-derived formula combining GPU compute throughput, PCIe bandwidth, and kernel launch overhead — not arbitrary thresholds. We validated this directly: a symbolic-bound triple-nested loop gets correctly flagged UNPROFITABLE because PCIe transfer time (0.15s) exceeds CPU compute time (0.10s), even though the GPU finishes the math in under 2ms. Every verdict is explained via SHAP in compiler-diagnostic style (Clang -Rpass), stating exactly which factors drove the decision — not just PROFITABLE/UNPROFITABLE, but why. Uncertain cases (pointer aliasing, data-dependent early exits) are explicitly flagged with capped confidence rather than guessed.

The LLVM Pass Transformation Analyzer (LPTA) bridges the gap between complex compiler optimizations and developer comprehension. Built for the SegFault 2026 hackathon by Team Kramer_Kodes, LPTA is an interactive web platform that demystifies how Clang and LLVM transform C++ code during the compilation process. The architecture features a Vite-React frontend with a live C++ workspace, connected to a Python FastAPI backend orchestrating the raw Clang and LLVM pipeline. When code is submitted, the backend natively executes LLVM optimization passes and captures the resulting Intermediate Representation (IR) telemetry in real-time. These transformations are surfaced through three core UI components: an Optimization Scoreboard tracking net code size changes, side-by-side Code Diffs highlighting exact line modifications, and interactive Control Flow Graphs (CFGs) visually mapping the execution paths of the compiled blocks. To make these deep technical concepts accessible, we integrated the Gemini API to provide context-aware, natural language explanations for each LLVM pass, detailing exactly why the compiler made specific structural decisions. By combining real-time compiler execution with AI-driven insights, LPTA transforms a traditionally opaque command-line process into a transparent, educational dashboard.

This project presents a simple functional programming language based on s-expressions and incrementally reduces it to the SKI combinatory calculus. The system first parses an AST (abstract syntax tree) and desugars the high-level syntax elements (such as let bindings) to produce a lambda calculus intermediate representation. While lambda calculus can theoretically represent all constructs, primitive literals and basic arithmetic operations are preserved to optimise verbosity and maintain practical brevity. This representation is then further translated to SKI combinatory calculus, which eliminates variables. The resulting SKI-trees are then evaluated using standard combinator reduction rules to yield the final computation. Additionally, the system features step-by-step visualisations at every stage of translation and evaluation, offering deep insights into the mechanics of functional language compilation and combinator reduction.

LPTA (LLVM Pass Transformation Analysis) makes a compilation like clang -O2 transparent. Compiling with optimization today is a black box: you see the input and the output, but never which of the hundreds of passes changed what. LPTA instruments the real optimization pipeline using LLVM's own PassInstrumentationCallbacks and records before/after metrics plus an IR hash for every pass execution — saving before/after IR diffs for passes that changed anything and measuring final codegen size per target with llc. Everything lands in an interactive dashboard: headline numbers, a nesting-aware pipeline timeline, a per-pass explorer with IR diffs, a flow ranking of top changers, cross-target codegen tables, an O0-vs-O2 compare engine with regression verdicts, and grounded AI explanations. On a 304-line demo, one -O2 run traced 1,756 events: 102 passes moved a counter, instructions went 109 to 112 while assembly grew 15% and LPTA names exactly which passes did it (SimplifyCFG −42, LoopVectorize +34). A 7-layer validation strategy — hand-counted ground truth, independent recounts, opt cross-checks, determinism, 87 unit tests, 300-iteration fuzzing — backs every number.

I built troid & robby. The Reverse-Obverse Image Duality (troid) explainable compiler turns a digital photograph into an Obverse-Reverse Image Object, or orio cookie – a two-sided proprietary image format viewed like a coin or postcard: an untouched obverse and a deterministically generated reverse, mutually exclusive to the sight. robby makes troid's underlying mechanism visible. A user picks an photo, writes a recipe, and deliberately compiles an orio. The live Teppanyaki Counter exposes the pipeline: source intake, metadata/C2PA inspection, pixel and palette measurement, recipe validation, IR generation, deterministic binding, reverse rendering, and pairing. It's a real compiler stack: a Rust lexer, parser, validator, IR, palette engine, renderer, and a WASM-connected browser interface. It separates authored from canonicalised instructions, source identity from pixel identity, C2PA presence from validation and signer trust, and private evidence from share-safe output. The original image stays sacred and immutable – robby never alters, recompresses or overwrites the obverse or its embedded credentials. The reverse is an emerging artwork and observability record, built from opaque image identity, colour material, explicit recipe settings, and bounded evidence, not from semantic recognition of the photo's content. The proposition: compilers can be beautiful instruments whose visible workings become part of the object they create.

Standard compilers (clang -O3) apply fixed, one-size-fits-all pass pipelines that miss massive workload-specific speedups due to the compiler Phase-Ordering Problem. Existing research tools like CompilerGym or OpenTuner rely on deprecated legacy pass managers, simulated environments, or lack real-world safety gates. I built Autotune Doctor: a production-grade, AI-guided compiler optimization and diagnostics system that discovers, validates, and mathematically proves custom LLVM New Pass Manager pipelines that outperform standard -O3. How Autotune Differs from Existing Tools: Physical Silicon, Zero Emulation: Unlike research sandboxes, Autotune benchmarks directly on physical microarchitectures (Apple Silicon ARM64, AMD/Intel x86_64) using nanosecond-precision hardware monotonic timers. Modern LLVM NPM Support (v14–22): Operates on modern LLVM New Pass Manager pipelines rather than obsolete legacy pass managers. Strict Bitwise Correctness Gates: Eliminates the silent miscompilations common in black-box AI compiler tuning with automated bitwise and checksum verification. Rigorous Statistical Proof: Replaces noisy single-run averages with Welch’s t-test (p < 0.05), Mann-Whitney U tests, and Cohen’s d-effect sizes to award evidence grades. Production Build Export: Unlike academic scripts, it generates drop-in CMake/Make recipes, optimized IR, and native CI performance gates (autotune guard). Distributed globally on PyPI (pip install autotune-doctor).

EEL is an ultra-lightweight, zero-dependency compiler and runtime for Linux eBPF, written entirely in ANSI C. It eliminates dependencies on Clang, LLVM, BCC, and libbpf, compiling domain-specific tracing scripts directly into verifier-compliant 64-bit eBPF bytecode. EEL features a complete compilation pipeline with lexical analysis, Pratt-style parsing, AST generation, semantic type checking, scoped symbol resolution, and direct eBPF code generation. It handles register allocation, bounded loops, conditional branching, jump backpatching, stack management, string synthesis, and kernel helper calls. The compiler outputs raw eBPF bytecode (.bin), static C headers (.h), and relocatable 64-bit ELF objects (.o). Its integrated loader uses direct sys_bpf() calls to load programs into the kernel, retrieves verifier logs on failure, dynamically registers kprobes through tracefs, attaches perf events, and streams kernel trace events in real time.

OCLens is a source-level debugger for OpenCL C kernels on the Portable Computing Language (PoCL) CPU backend—the software execution path called for by the SegFault 2026 challenge when vendor GPU driver hooks are out of reach. GDB can already stop inside PoCL’s lowered work-group code, but it speaks native CPU semantics, not OpenCL: work-items become compiler loops, private variables become context arrays, and a single source breakpoint fires for every work-item. OCLens is a GDB Python extension and CLI that adds the missing semantic layer. Developers set breakpoints on their original .cl files, select a global or local work- item, run the host program, and get one intentional stop—not N—at the chosen line. LLVM DWARF supplies source-level names; our ValueProjector maps PoCL’s per-work-item storage back to scalars the developer recognizes. Stepping (ocl- next) preserves the active work-item across source lines. We prove the workflow end-to-end on stencil_barrier_bug: sixteen work-items, two work-groups, __local memory, a barrier, divergent control flow, and a real arithmetic bug verified by the host (gid=5: expected 24, actual 2). Halting uses only GDB and ptrace on PoCL’s JIT output—no proprietary GPU APIs. PoCL-specific knowledge is isolated in PoclAdapter; docs and 39 unit plus GDB integration tests make the demo reproducible via oclens doctor, Docker, and CI.

Pointer analysis is an important technique in modern compilers and static analyzers: it identifies which pointers may alias each other, and enables optimizations, memory-safety checking, and cross-procedural reasoning. But every existing tool is a black-box: it provides a result, but not an explanation of how it was obtained. PTA-Viz is the first interactive, step-by-step visualizer for flow- and context-sensitive pointer analysis. It accepts programs in a C-like intermediate language (or via our built-in C→IR transpiler) and runs four algorithms simultaneously, providing a visual explanation of each. Four algorithms, four levels of precision: • Andersen's (FI, CI): visualize expansion of inclusion-constraint sets, one iteration at a time • Steensgaard's (FI, CI): see union-find equivalence classes being merged during execution • FS-PTA (FS, CI): examine per-statement IN/OUT pointer graphs as the fixed-point converges • VASCO (FS, CS): trace the context-cloning tree, memoization cache hits, and recursion guards (now visible for the most precise algorithm) The GUI displays a clickable control-flow graph: clicking a node synchronizes all result panels to that program point, and an iteration stepper lets you walk through convergence step by step. We fixed five undocumented bugs in the VASCO engine, and added a globals: section and C-to-IR converter to analyze real C programs directly.

LLVM-Lens is an LLVM Pass Transformation Analyzer that helps in visualizing the compilation pipeline for a given C/C++ codebase. During the compilation process, various LLVM Passes may affect the final optimized LLVM IR generation. Along with the default passes, users can write custom passes for additional instrumentation of the code. With the help of LLVM-Lens, users can generate a static HTML report to visualize all the passes, with support for custom passes as well. For each stage of the pipeline, users can view the changes in LLVM IR, various analyses that are run and invalidated, CFG, and other compilation graphs. There is also an option to get a `blame` view where the user can probe each line of LLVM IR and find the passes that have created, renamed, or rewritten it. Along with support for LLVM IR, we have support for Machine IR (MIR) as well. Users can visualize the MIR pipeline in a similar manner to the LLVM IR pipeline. Additionally, the physical register allocation and register spills can be viewed as well. Every line also maps back to C/C++ source through debug info. AI is integrated that can help users to understand pass details.

Praline is a local prototype for parallelizing supported C loops that call helper functions. It uses a Clang syntax tree, helper-effect summaries and conservative dependency checks under explicit alias and bounds assumptions. Each decision includes source evidence. Safe loops can produce CPU OpenMP source or GPU target source with configured array extents and device-available helpers. The harness discovers toolchain capabilities, compiles comparable variants, compares every output element with serial execution and an independent reference, and records repeated kernel and end-to-end timings. The helper-map demonstration passed 30 size, seed and thread validation cases on an arm64 Mac. Five-trial measurements expose OpenMP overhead on this simple workload rather than claiming universal speedup. Negative examples cover hidden global writes, cross-iteration dependencies, colliding writes, unresolved aliasing and unsupported calls. A plain HTML report separates generated, validated and measured evidence. Praline uses Clang rather than ROSE. GPU source is generated, but device execution remains unverified.

Cost models in production optimizing compilers face a fundamental trade-off: classical polyhedral heuristics rely on rigid analytical formulations that fail to capture modern microarchitectural non-linearities, whereas deep neural surrogates introduce unacceptable compilation latency overheads and out-of- distribution performance regressions. We present pRNG, an in- tree polyhedral cost modeling framework directly integrated into the LLVM middle-end optimization pipeline. pRNG introduces a hybrid predictive engine combining recursive Tree-LSTM structural abstract syntax tree (AST) embeddings, 35-dimensional ScalarEvolution microarchitectural feature extraction, and pass- specialized Gradient Boosted Decision Tree (GBDT) ensembles. By transpiling trained models into native C/C++ inline branch tables and enforcing epistemic confidence safety gating (τ), pRNG eliminates external runtime dependencies and suppresses offline holdout slowdown risks from 46.49% to 2.23% across 60,220 schedules. Evaluated on physical host execution against upstream Stock Clang -O3 and GNU GCC -O3, pRNG achieves a +13.3% geometric mean speedup (+37.3% on 5-D tensor contractions, +35.5% on polyhedral loop nests) over Stock Clang, with hardware performance counter profiling confirming a 75.0% reduction in L1-D cache misses and 100% vector register spill freedom.

Interactive debugging for OpenCL programs or CUDA programs is currently done via GDB. GDB is not designed for stepping GPU kernels or visualising the state of an entire work-group composed of several work-items simultaneously. For example, it is difficult to visualise bugs arising due to work group divergence over the interface GDB provides. This project aims to fully redesign the debugger interface for debugging GPU kernels and provide a richer visualisation that aids in catching bugs faster and develop good mental model for execution of GPU kernels. vodd implements its own custom interpreter for OpenCL kernels, serves an interactive debugger over http via the browser and borrows all error detection algorithms from Oclgrind.

We built oclgdb, a real source-level debugger for OpenCL kernels — the thing that doesn't exist unless you work at Nvidia or AMD. Right now, debugging a kernel running on a GPU means printf statements and squinting at raw registers. Production debuggers exist, but they're locked behind proprietary driver hooks nobody outside a GPU vendor can touch. Our way around that: target pocl's CPU backend instead of real silicon. pocl compiles OpenCL C down to LLVM IR and drops each kernel onto disk as an ordinary ELF .so, which means Clang's DWARF debug info comes along for free, and halting a work-item is just ptrace and an INT3 — the same trick GDB itself uses on Linux. No JIT to hook, no driver to reverse-engineer. The part that actually took effort: GPU kernels don't have "a" state. A work-group runs 64 work-items through one shared stack frame, and pocl keeps their variables in registers with lifespans of a few instructions — work-item 12's values are gone the moment work-item 13 starts. So we snapshot every work-item's resolved variables the instant it hits a breakpoint, and figuring out which work-item a given trap belongs to (workitem.cpp's identity calibration) was the hardest problem in the whole project. It works: we set a breakpoint filtered to global work-item (255,0,0) in a box-blur kernel, ran it, and read gid == n evaluate to false at the source line — catching a real off-by-one before it silently corrupted output.

PolicyLang is a human-readable Domain-Specific Language (DSL) and compiler designed to simplify the creation of network security policies using eBPF. Writing eBPF networking programs directly requires knowledge of low-level packet structures, Linux networking, C, and kernel-level programming. PolicyLang addresses this by allowing users to express security intent using simple rules such as allow ingress when destination.port == 443. The system implements a complete compiler pipeline consisting of lexical analysis, parsing, AST construction, semantic validation, intermediate representation (IR), optimization, and eBPF code generation. A Flask-based API connects the compiler with an interactive web-based policy editor, allowing users to enter policies and inspect compilation results. The generated eBPF-compatible C code can be compiled using LLVM/Clang into an eBPF ELF object and inspected using Linux eBPF tooling such as bpftool. This creates an explainable chain from high-level security intent to low-level eBPF instructions. The project has been validated with 49 automated tests covering major compiler stages and policy validation. PolicyLang demonstrates how compiler technology can make programmable network security more accessible, transparent, and extensible while preserving visibility into how a high-level security policy becomes an eBPF program.

Cerberus is an intelligent, physics-constrained compiler optimization framework and GPU offload profitability predictor that eliminates devastating 10x-20x slowdowns caused by naive GPU parallelization. Traditional compilers are blind to interconnect physics: offloading memory-bound loops over PCIe saturates transfer latency (t_transfer >> t_kernel), turning potential speedups into severe regressions. Cerberus acts as a data-driven compiler gatekeeper. Our pipeline couples LLVM libclang AST semantic extraction (capturing 12 hardware-agnostic loop features including operational arithmetic intensity, spatial/temporal cache reuse, SIMD coalescing, and loop-carried data hazards) with direct C-ABI OpenCL host silicon register discovery. To prevent single-device bias, we curated a ground-truth dataset of 2,318 physical benchmark executions across 5 heterogeneous hardware architectures (NVIDIA RTX dGPU, AMD RDNA3 iGPU, macOS AMD dGPU, Tesla T4 Cloud, and Intel APUs). Our Two-Stage Hurdle XGBoost model enforces monotonic physical constraints to achieve 91.33% offload gating accuracy, 0.967 ROC-AUC, and 0.836 R2 score. Crucially, Cerberus couples decision-making with TreeSHAP mathematical explainability and Williams Roofline ceilings, automatically synthesizing optimized OpenMP 4.5+ target directives with dynamic runtime crossover guards (if(N >= Threshold))—delivering up to 1242x speedup on compute-heavy kernels while keeping memory-bound loops on CPU.

Clang LibTooling source-to-source tool that parallelizes unmodified sequential C for GPGPU. Naive parallelizers miss loops whose body calls a helper function, since judging safety needs reasoning across that function boundary, and they treat every safe loop as worth parallelizing, when launch and thread-start overhead can outweigh the work. For every loop, the tool resolves callees transitively across function boundaries via Clang's CallGraph, then computes a tri-state safety verdict (SAFE/UNKNOWN/UNSAFE) from two checks: does a reachable function write through a pointer parameter or global, and does the loop body carry a cross-iteration dependence. Every SAFE loop is priced with a roofline-style cost model (sequential vs. CPU-threaded vs. GPU-offload) to decide GPU_OFFLOAD/CPU_PARALLEL/SEQUENTIAL, then the source is rewritten with the matching OpenMP 4.5+ pragma and map() clauses. Correctness is verified by exact per-element comparison, not checksum, and both checks are proven to discriminate on matched pass/fail fixtures. Timing is measured on real hardware across three policies: sequential, a naive "offload everything safe" baseline, and this tool's gated policy. One honest finding is reported alongside the wins: naive sometimes beats gated, because gating a file's only OpenMP construct still pays libomp's runtime cold-start cost regardless of the guard, a cost the model has no term for. Repository: github.com/adhithyaragavan/gpgpu-autoparallel

OCaml 5's effect handlers are untyped. The compiler does not check that a performed effect is handled, and no signature can record that a function requires one, so there is no way to find out what a library asks of you short of reading its source. unhandled recovers that from the compiler's own output. It reads the .cmt files a normal dune build already leaves on disk, infers a per-function effect set by fixpoint over the call graph, and prints the contract: which effects each function requires its callers to handle. No annotations, no forked compiler, no changes to anyone's code. We ran it across the ecosystem and committed the result: 16 libraries, 458 functions, regenerated by one command. A --baseline flag turns that contract into a CI check, so a pull request that changes what your library demands of its users fails the build, with the function and the effect named in the diff. We test the analyser against execution rather than against our own expectations: generate a random effectful program, ask the checker what will happen, then run it and compare. Zero false negatives over 1000 generated programs. Thomas Leonard, the author of Eio, reviewed the work and asked for the case a runtime check cannot see: Lwt code performing an Eio effect that is handled and still deadlocks. We built it as E005 and it fires on his own library. OCaml 5.3 and 5.4, both green in CI. MIT licensed. Repository: github.com/manishpaulish/unhandled

Bpflens is an explainable static-analysis tool for eBPF safety reasoning. It analyzes LLVM IR, builds control-flow and abstract program state, tracks safety proofs and value provenance, and detects unproven packet bounds and nullable map-pointer accesses. Instead of only reporting an unsafe access, Bpflens explains the missing proof and traces its origin back to source code.

RoofPick is a roofline driven optimization advisor for Numba JIT compiled Python loops. It analyzes a loop's Numba Typed SSA statically, with no execution, to classify it as compute bound or memory bandwidth bound against the host machine's calibrated roofline, and recommends, and can automatically apply, the right LLVM transform (vectorize, tile, unroll, or fuse) instead of relying on Numba's one-for-all defaults. Validated against real hardware counters, it recovers about 97% of the best available pipeline's performance, edging out Numba's own default.

thecoolestcompiler takes plain sequential C/C++, works out which loops can safely run in parallel, and adds the OpenMP pragmas for you. Most auto-parallelizers stop at the loop body. If a loop calls a helper, they give up. This one doesn't. It builds a call graph, collapses recursion with Tarjan SCCs, and pushes read/write sets bottom-up until they settle. So if accumulate() quietly mutates a global, it gets caught and the loop stays serial. Every loop gets a verdict: PARALLEL_SAFE, REDUCTION_CANDIDATE, SERIAL_ONLY or UNKNOWN_CONSERVATIVE. Each comes with a reason you can actually read. Safe doesn't mean worth it. So it profiles first. Pass 1 injects counters and runs the code. Pass 2 feeds real numbers into a roofline model. A loop at 0.25 FLOP/byte vs an 11.1 ridge point is memory-bound, so it stays on the CPU instead of paying PCIe cost on a GPU. Clang 18 parses, ROSE 2.14 analyzes. Our ROSE build had no C/C++ frontend, so the AST is built by hand. One rule never bends: can't prove it's safe, don't parallelize it. A false "safe" is a data race. A precision fix once flipped an unsafe loop to safe. It got reverted. Results: 11/11 tests pass from a clean clone. Output matches sequential byte for byte. ~1.2x speedup on 2 shared vCPUs, about what bandwidth allows there. Next up: scalar reductions and multi-dim arrays.

What we built: LPTA is a tool that watches LLVM's compiler optimizations run and shows, in one simple timeline, exactly which pass changed the code, how much it changed (real instruction/load/store/branch counts), and what that change means in plain English — instead of a developer manually collecting and comparing raw IR dumps. Our approach: We reuse LLVM's own tools (clang + opt) to capture the code before/after each pass with zero custom compiler code, then measure real structural changes using llvmlite, attach short explanations from a simple data file, and show it all as a browsable web timeline — built in three clean layers (capture → analysis → presentation) so each part can be upgraded on its own. Future updates: letting users pick which passes to analyze, covering all LLVM passes (not just the common ones), showing pass timing graphs, connecting IR changes to final assembly, comparing two compiler runs side by side, and optionally using AI to auto-explain undocumented passes — all addable without rebuilding what already works.

TritonFlow is a schema-driven compiler framework for programming custom AI accelerators without building a new target-specific compiler backend for each architecture. We built a prototype that connects PyTorch through torch.compile and Triton IR to a target-independent compilation pipeline. Instead of hard-coding instruction mappings, TritonFlow describes an accelerator through a YAML schema containing its instructions, constraints, costs, register and memory characteristics. The compiler analyzes Triton programs, recovers affine memory access patterns into explicit descriptors, and uses the target schema to select appropriate instructions and memory operations. The same intermediate representation can therefore be lowered to different accelerator models, including systolic, banked-memory, and SIMT architectures. We also built a software emulator and fail-closed validation path to check generated programs, numerical behavior, and unsupported operations. Additional demonstrations include structured 2:4 sparsity, where the compiler recognizes the pattern and selects a specialized sparse tensor instruction. TritonFlow is designed as an architectural research prototype showing how declarative hardware descriptions can reduce the amount of target-specific compiler engineering required when exploring new AI accelerator designs.

Abstract Compiler optimization plays a critical role in improving program performance, but applying an optimization does not always guarantee a speedup. Transformations such as loop unrolling, vectorization, loop tiling, and loop fusion can introduce additional instructions, memory overhead, or code complexity, making optimization profitability dependent on the characteristics of the target code. This project presents a Compiler Cost Model for Optimization Profitability that predicts whether applying a particular optimization to a candidate loop is likely to be beneficial. The system combines a lightweight LLVM-based feature extraction pipeline, optimization-specific machine learning models, and a hand-designed LLVM heuristic cost model. The LLVM pass identifies annotated optimization candidates and extracts relevant static features from LLVM IR, including loop depth, trip count, instruction counts, memory operations, arithmetic operations, branch behavior, memory access patterns, reduction information, and optimization-specific characteristics. Separate feature sets are used for loop unrolling, vectorization, tiling, and fusion because the factors influencing profitability differ across transformations. The extracted features are passed to optimization-specific Random Forest classification models, which predict whether a transformation is profitable and provide a confidence probability. In parallel, an LLVM-based heuristic model estimates profitability using