SegFault 2026 — Where impossible is just an error code.

Where impossible is just an code

An online hackathon on compilers and programming languages. Five weeks to build. Finalists present in person at IISc, Bengaluru on Oct 2–3, 2026

SegFault is organised as part of the Innovations In Compiler Technology workshop

Registrations are closed

Fully onlineCompilersProgramming languagesProgram analysisLLVM · MLIROpen to students & industryRolling shortlistsFinale at IISc BengaluruFully onlineCompilersProgramming languagesProgram analysisLLVM · MLIROpen to students & industryRolling shortlistsFinale at IISc Bengaluru

The format

Everything is online.Except the finale.

Build from anywhere. Only the finale is in person.

Fully onlineAug 1 – Oct 3, 2026

Anywhere001

No travel to take part.

Any city, any timezone. Nothing to book.

Entry002

Registrations have closed.

Sign-ups ended on Aug 15, 2026.

Shortlisted teams get their next steps by email.

Shortlists003

Announced as they land.

Teams are shortlisted as submissions come in, all through the five weeks.

Submit early, hear back early.

The finale004

One trip, at the end.

Finalists present in person at IISc, Bengaluru on Oct 2–3, 2026.

Their IICT workshop attendance is covered. Nothing before it needs a flight.

Tracks

Six problem statements.Eight open themes.

Every team picks exactly one of either: an official problem statement from the organizers, or an open theme with an idea of your own.

Official problem statements

P01 · Explainable compilers

LLVM Pass Transformation Analyzer

LLVM applies a large sequence of optimization passes, but understanding how the complete pipeline transforms a program is difficult. LLVM provides individual diagnostics and debugging options, but developers still lack a unified view that correlates which pass changed the IR, what changed, and how significant that change was. As a result, investigating optimization and performance regressions often requires manually collecting and comparing IR from multiple stages of the pipeline.

Full brief ↓

Problem

Goal

Build an LLVM-based analysis tool — the LLVM Pass Transformation Analyzer (LPTA) — that records IR state before and after each optimization pass and presents the resulting transformation history as a single, explainable view. The tool should connect individual passes to measurable, quantified changes in the IR, making the optimization pipeline's behavior traceable rather than opaque.

Expected outcome

The tool will give compiler developers and performance engineers an explainable, evidence-backed view of LLVM's optimization pipeline: which passes ran, what they changed, how significant each change was, and how it affected final codegen. This turns manual, multi-stage IR comparison into a repeatable workflow for understanding optimization behavior and — where cross-run comparison is implemented — investigating performance regressions directly.

P02 · Explainable compilers

AI Compiler Optimization Explorer

Modern AI compiler stacks lower a model through several distinct IR levels — for example Torch FX → StableHLO → Linalg → Affine → LLVM IR — each applying its own transformations and optimizations. This multi-stage lowering is powerful but opaque: developers have no unified way to see how a model's representation and structure evolve across stages, which optimizations were applied at each level, or where a particular inefficiency was introduced or resolved. Diagnosing why a model compiles the way it does currently requires manually dumping and inspecting IR at each stage separately.

Full brief ↓

Problem

Goal

Build an interactive visualization tool that captures a model's representation at each compiler stage in a real Torch-to-LLVM (or similar) lowering pipeline, and presents the transformation across stages as a single explorable view — showing not just the IR at each level, but which optimizations were applied in getting from one stage to the next.

Expected outcome

An interactive explorer that makes a real multi-stage AI compiler pipeline legible end-to-end — letting a developer see exactly how a model transforms from framework-level graph down to LLVM IR, what optimizations fired at each stage, and where a specific operation ends up — replacing manual, stage-by-stage IR dumping with a single navigable tool.

P03 · Compilers and AI/ML

Compiler Cost Model for Optimization Profitability

Compiler optimizations — loop tiling, vectorization, unrolling, and fusion — are not universally beneficial. Applied indiscriminately, they can just as easily degrade performance as improve it, due to factors like low trip counts, poor memory access patterns, register pressure, or cache-unfriendly access. Compilers today generally rely on fixed, hand-tuned heuristics to decide whether to apply a given optimization, which don't generalize well across workloads and don't explain their own decisions. There is a need for a cost model — heuristic and/or learned — that predicts the profitability of an optimizing transformation before it's applied, so that the compiler can be selective rather than blanket in applying it.

Full brief ↓

Problem

Goal

Build a compiler cost model that takes a candidate code region (loop or function) and a candidate optimization (tiling, vectorization, unrolling, or fusion) and predicts whether applying it will improve performance — using code features such as loop trip count, memory access patterns, computational intensity, and cache locality. The model should be usable both as a standalone predictor and integrated into a real compiler pipeline (LLVM/MLIR), and should support two tiers of ambition: a feature-driven heuristic baseline, and a machine-learned model trained on benchmark data.

Expected outcome

A working cost model — available in both a lightweight heuristic form and a trained ML form — that a compiler can consult before applying a costly optimization, reducing the frequency of performance-degrading "over-optimization." Success is demonstrated by the model matching or beating the compiler's existing heuristics on a real benchmark suite, with explainable predictions and measurable speedup on the subset of transformations it recommends.

P04 · Compilers and AI/ML

Parallelization Profitability Predictor for GPU

Offloading a candidate loop or code region to the GPU is not always beneficial. Automatic or naive GPU parallelization can easily produce slower programs than the sequential CPU baseline, due to insufficient data parallelism to amortize host-device transfer cost, poor memory coalescing, high kernel launch overhead, or excessive host-device synchronization. Developers and compilers alike lack a systematic, data-driven way to decide, before offloading, whether a given region is actually GPU-profitable rather than merely GPU-safe.

Full brief ↓

Problem

Goal

Develop an ML-based framework that predicts whether a candidate code region should be parallelized on the GPU before OpenMP 4.5+ target offload or OpenACC directives are applied. The framework should extract static code features (trip count, memory access pattern, data volume, computational intensity), optionally collect runtime profiling data where static analysis is insufficient, train a model on labeled examples of profitable vs. non-profitable GPU offload, and predict profitability for new candidate regions — with an explanation for each prediction so a developer can trust and validate the model's decision.

Expected outcome

A predictor that, given a candidate code region, reliably distinguishes GPU-profitable from GPU-unprofitable offload candidates, measurably reducing the incidence of slowdowns from indiscriminate GPU parallelization. Success is demonstrated by the model's predictions correlating with actual measured speedup/slowdown on a real benchmark suite, with explainable, feature-grounded rationale accompanying each prediction — and, ideally, integration as a gating check ahead of automatic OpenMP/OpenACC GPU offload directive generation.

P05 · Optimizing for the real world

Automatic Parallelizing Compiler for GPGPU with Interprocedural Analysis

Automatic parallelization is typically limited to single-function, CPU-threaded scope, missing two major classes of opportunity: parallelism visible only across function boundaries (a hot loop calling a helper function whose aliasing/side effects determine parallel-safety), and parallelism that is actually GPGPU-suitable rather than merely CPU-thread-suitable. Most auto-parallelizing compilers either don't attempt interprocedural analysis at all, or attempt it but target only CPU threads (OpenMP/OpenACC on host), leaving substantial data-parallel workloads unexploited on GPU hardware. There is a need for a parallelizing compiler framework that performs whole-program interprocedural dependence analysis and then reasons explicitly about whether an identified parallel region is a good candidate for GPGPU offload — not just whether it's safe to parallelize at all. Rather than building this analysis infrastructure from scratch, teams are encouraged to build on ROSE (LLNL's open-source compiler framework, github.com/llnl/rose), which provides a mature C/C++ (and Fortran) source-to-source frontend with existing support for applications using UPC, OpenMP, and CUDA, along with program analysis and transformation infrastructure. ROSE's CUDA-awareness in particular makes it a reasonable base for identifying and reasoning about GPU-relevant code regions, rather than treating GPU codegen as a bolt-on to a CPU-only analysis.

Full brief ↓

Problem

Goal

Design and implement a compiler framework — built on top of ROSE — that automatically identifies parallelizable regions in sequential C/C++ programs through whole-program interprocedural analysis, and targets those regions for GPGPU execution via OpenMP 4.5+ target offload directives (target, teams, distribute, parallel for, with associated data-mapping clauses), falling back to CPU-threaded OpenMP/OpenACC where a region is safe to parallelize but not GPU-profitable.

Expected outcome

A ROSE-based compiler framework that takes real, unmodified sequential C/C++ programs — including ones with function calls inside hot loops, which naive parallelizers typically skip — and produces correctly parallelized code that targets GPGPU execution where profitable and CPU threading otherwise, validated against standard benchmarks. Success is demonstrated by parallelism correctly found across function boundaries that intraprocedural analysis would miss; a GPU-suitability decision that measurably outperforms a naive "offload everything safe" policy; and substantiated speedup on GPU-suitable benchmarks with correct host-device data movement and numerically validated results.

P06 · Compiler frameworks and tools

Source-Level OpenCL Debugger for GPU Architectures

OpenCL kernels running on GPUs are difficult to debug because developers lack source-level visibility into execution — they're forced to reason about raw ISA state instead of variables, breakpoints, and stepping the way they would with CPU code. Production-grade GPU debuggers exist but rely on vendor-proprietary driver hooks that are inaccessible to most tooling efforts within a short build cycle. There is a need for a debugger that gives developers a genuinely source-level debugging experience for OpenCL kernels — breakpoints, variable inspection, and stepping — without requiring hardware-level driver access, by targeting a software execution backend that models GPU execution semantics (work-items, work-groups, divergence) faithfully enough to be useful.

Full brief ↓

Problem

Goal

Build a source-level OpenCL debugger targeting pocl (Portable Computing Language) running kernels on its CPU device backend, or an existing OpenCL/GPU simulator (e.g., Oclgrind), rather than real GPU silicon. Since pocl lowers OpenCL C to LLVM IR and executes work-items as software constructs on the CPU, the team can leverage LLVM's mature, already-existing DWARF debug-info generation instead of inventing GPU ISA-level debug metadata from scratch, and can implement breakpoint halting via standard OS-level mechanisms (ptrace, or hooking the interpreter/JIT) instead of GPU driver hooks. The tool should still faithfully model GPU-relevant semantics: multiple work-items per work-group, per-work-item state isolation, and the ability to select which work-item's state to inspect at a breakpoint. Teams with time remaining are encouraged to explore extending the approach toward an open, debuggable GPU simulator target (e.g., gem5-gpu, MGPUSim, or the RISC-V GPGPU work referenced in other tracks of this hackathon) as a stretch direction, since real vendor driver access is not realistically obtainable within the hackathon timeframe.

Expected outcome

A working prototype that lets a developer compile an OpenCL kernel (via pocl), set a source-line breakpoint, run it, have execution genuinely halt at that line for a selectable work-item, inspect that work-item's variables (resolved to source-level names via LLVM debug info) and relevant memory, then step/continue correctly — demonstrated end-to-end on a real, bug-containing multi-work-item kernel. This gives developers a usable source-level debugging workflow for OpenCL today, and the LLVM-debug-info-based approach is directly extensible to a real GPU backend later, since the hardest, vendor-gated part — hardware-level halting — is exactly what's deferred out of scope for this cycle.

Open themes · bring your own idea

fn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x yfn pass ir ssa cfg type match emit let llvm opt loop { } => :: [] () * ; 01 10 x y

Domain specific compilers and languages

Design and implement compilers and languages for a specific application or a specific piece of hardware.

Halide for computational photography · a language for drones · theorem prover languages

Compilers
Programming languages
eDSLs

Compiler frameworks and tools

Work on the infrastructure itself: intermediate representations, program analysis, transformation tooling.

static analysers · debuggers · formatters and review tools · coverage and profiling

Tools
Static analysis
Debugging

Compilers and AI/ML

Use AI/ML to make compilers better, or compiler technology to make AI/ML workflows better.

LLM support for CFGs · AI-assisted review · model-guided pass selection

Machine learning
Codegen
Tooling

Optimizing for the real world

Take software that already exists and make it run faster or leaner with compiler techniques.

auto-tuning heterogeneous systems · energy-efficient codegen · edge instruction selection

Auto-tuning
Energy
Edge

Explainable compilers

Modern compilers are enormous black boxes. Make their decisions legible to the people using them.

IR to ASM visualisation · showing why a pass fired · interactive teaching tools

Visualisation
Teaching
Debugging

Compilers for new paradigms

Build compilers or tooling for places compilers are only just arriving.

eBPF and secure enclaves · quantum IR to gates · attack-surface reduction

Quantum
eBPF
Security

Functional programming

Build using functional programming languages, or build the tooling that makes them better.

OCaml and Haskell projects · type-checker tooling · effect systems in practice

OCaml
Haskell
Type systems

Open innovation

Build anything on compiler technology. If it does not fit the other tracks but it is compilers, it fits here.

your own problem statement, as long as compiler technology is at its core

Anything compilers
Your idea

One pick per team · a problem statement or a theme

Timeline

Two months, end to end.Here is how it runs.

Aug 1 – Oct 3, 2026. Fully online until the finale in Bengaluru.

Aug 1

Registrations open

Aug 7

Problem statements and tracks announced

The real track list and problem statements land a week after sign-ups open.

Aug 15

Registrations close

Late entries are still accepted once hacking is underway.

Aug 15same day

Hacking begins

Five weeks, fully remote. Everything runs on your own machine.

Rollingcontinuous

Shortlists announced

Teams get shortlisted as submissions come in, instead of all at once on one date.

Sept 19–20

Final evaluation

Online judging across both days. The finalist list is locked by the end of it.

Oct 2–3

Grand finale at IICT

Finalists present in person at IISc Bengaluru, alongside the IICT workshop.

VenueA V Rama Rao Auditorium, Indian Institute of Science

Prizes

Cash for the top three teams.

₹2,00,000 in total, plus certificates and mentorship for everyone who takes part.

Total prize pool

₹2,00,000

Certificates

Every participant gets a certificate.

Mentorship

Sessions with compiler engineers working in industry.

Travel

Finalists' IICT workshop attendance is covered.

Hiring

Internship and job conversations with the sponsors.

Sponsors.

Sponsor 01

CDAC

Centre for Development of Advanced Computing

cdac.in

Sponsor 02

FP Launchpad

Centre for Functional Systems Research and Education, IIT Madras

fplaunchpad.org

Host

SegFault is organised as part of the Innovations In Compiler Technology workshop.

Innovations In Compiler Technology

FAQ

Everything is online.Except the finale.

No travel to take part.

Registrations have closed.

Announced as they land.

One trip, at the end.

Six problem statements.Eight open themes.

LLVM Pass Transformation Analyzer

AI Compiler Optimization Explorer

Compiler Cost Model for Optimization Profitability

Parallelization Profitability Predictor for GPU

Automatic Parallelizing Compiler for GPGPU with Interprocedural Analysis

Source-Level OpenCL Debugger for GPU Architectures

Domain specific compilers and languages

Compiler frameworks and tools

Compilers and AI/ML

Optimizing for the real world

Explainable compilers

Compilers for new paradigms

Functional programming

Open innovation

Two months, end to end.Here is how it runs.

Registrations open

Problem statements and tracks announced

Registrations close

Hacking begins

Shortlists announced

Final evaluation

Grand finale at IICT

Cash for the top three teams.

Sponsors.

CDAC

FP Launchpad

Questions people ask.

Registrationsare closed.

Everything is online.Except the finale.

No travel to take part.

Registrations have closed.

Announced as they land.

One trip, at the end.

Six problem statements.Eight open themes.

LLVM Pass Transformation Analyzer

AI Compiler Optimization Explorer

Compiler Cost Model for Optimization Profitability

Parallelization Profitability Predictor for GPU

Automatic Parallelizing Compiler for GPGPU with Interprocedural Analysis

Source-Level OpenCL Debugger for GPU Architectures

Domain specific compilers and languages

Compiler frameworks and tools

Compilers and AI/ML

Optimizing for the real world

Explainable compilers

Compilers for new paradigms

Functional programming

Open innovation

Two months, end to end.Here is how it runs.

Registrations open

Problem statements and tracks announced

Registrations close

Hacking begins

Shortlists announced

Final evaluation

Grand finale at IICT

Cash for the top three teams.

Sponsors.

CDAC

FP Launchpad

Questions people ask.

Is SegFault 2026 actually online?

What does it cost, and who can take part?

Can I still join after Aug 15?

How does shortlisting work?

What happens at the finale?

My question isn't here.

Registrationsare closed.