COMPILER DESIGN
HACKATHON 2026
Problem Statements — [Link] Students
Duration: 24 Hours | Teams: 2–4 Members | All Units Covered
Department of Computer Science & Engineering
PS-01 — MiniLex — Visual Lexical Analyzer
Unit: Unit I: Introduction to Compilers Syllabus Topics: Regular Expressions, Finite Difficulty: Medium
Automata, NFA, DFA, LEX, Bootstrapping
Background
Lexical analysis is the first and foundational phase of every compiler. Millions of students study regular
expressions and finite automata from textbooks but rarely see how they connect in practice. A visual,
interactive tool that bridges regex theory with DFA construction can dramatically improve learning
outcomes.
Problem Statement
Build a web-based lexical analyzer generator where a user can:
1. Define token types using regular expressions (keywords, identifiers, literals, operators)
2. Input a sample source program in a custom mini-language
3. Watch the lexer tokenize input step by step with highlighted DFA state transitions
4. Visualize the complete NFA construction from regex and the subset construction to DFA
Deliverable
A working browser-based tool that accepts regex-based token rules, converts them to NFA then DFA
(subset construction), and tokenizes sample input with an animated state-transition display and a
tokenized output table.
Judging Criteria
1. Correctness of regex → NFA → DFA pipeline
2. Visual clarity of state machine transitions
3. Accuracy of tokenizer output against test cases
4. Code modularity (separate lexer, NFA, DFA modules)
5. Demo and UI quality
Recommended Technology Stack
Python / JavaScript / Java — any stack. Recommended: Python (re module) + Flask + [Link] for
visualization.
Bonus Challenge (+10 marks)
Support LEX-style input format (token rules file) and generate a standalone tokenizer script
(bootstrapping demo).
PS-02 — Interpreter vs Compiler Profiler
Unit: Unit I: Introduction to Compilers Syllabus Topics: Phases of Compiler, Difficulty: Beginner
Interpreter, Pass & Phases, Translation
Background
The difference between compilation and interpretation is foundational to computer science, yet students
often struggle to articulate the tradeoff in concrete, measurable terms. A profiling tool that runs the same
program through both paths and reports phase-level timings makes this difference tangible and
memorable.
Problem Statement
Build a profiler that accepts programs written in a simple custom language (supporting assignments,
arithmetic, print statements, and loops) and:
5. Runs the program through a built interpreter (parse-and-execute)
6. Runs the same program through a compiler → bytecode → virtual machine path
7. Reports phase-wise timing (lexing, parsing, code generation, execution) for both paths
8. Shows a side-by-side comparison dashboard with memory usage and instruction counts
Deliverable
A profiling dashboard that executes a given program via interpreter and compiler paths, annotating each
compilation phase with its execution time and producing a comparison report.
Judging Criteria
1. Correctness of both interpreter and compiler execution
2. Accuracy of phase-level timing measurements
3. Quality and clarity of the comparison dashboard
4. Coverage of language features in the custom mini-language
5. Documentation of tradeoff findings
Recommended Technology Stack
Python recommended (ast module, timeit). Front-end in any framework.
Bonus Challenge (+10 marks)
Add an optimization flag to the compiler path and show how it changes the phase profile.
PS-03 — ParseViz — Interactive Parse Tree Generator
Unit: Unit II: Parsing (Top-Down) Syllabus Topics: CFG, LL(1), Ambiguity, Left Difficulty: Medium
Recursion, Left Factoring, FIRST/FOLLOW
Background
Context-free grammars, derivations, and parse trees are among the most abstract topics in compiler
design. Students frequently memorize the elimination steps for left recursion and left factoring without
understanding why they are necessary. An interactive tool that shows the grammar transformation step by
step can bridge this gap.
Problem Statement
Build a grammar explorer where a student can:
9. Input any context-free grammar and a test string
10. Detect and eliminate left recursion automatically, showing before/after grammar
11. Apply left factoring and show the transformed grammar
12. Compute FIRST and FOLLOW sets for all non-terminals
13. Build the LL(1) parsing table and detect conflicts
14. Animate the parse of the test string showing stack contents and input pointer at each step
15. Generate and display the parse tree visually
Deliverable
An interactive grammar analysis tool covering the complete LL(1) parser construction pipeline: left
recursion elimination → left factoring → FIRST/FOLLOW → parsing table → animated parse → parse
tree.
Judging Criteria
1. Correctness of left recursion elimination
2. Correctness of FIRST and FOLLOW set computation
3. Accurate LL(1) table construction with conflict detection
4. Parse tree visual quality and animation smoothness
5. Handles edge cases: epsilon productions, multiple conflicts
Recommended Technology Stack
Python + any visualization library (networkx, graphviz, [Link]). Web front-end encouraged.
Bonus Challenge (+10 marks)
Support export of the parsing table as a formatted spreadsheet and the parse tree as SVG.
PS-04 — GrammarFix — Dangling-Else Resolver
Unit: Unit II: Parsing (Top-Down) Syllabus Topics: Ambiguity Elimination, Difficulty: Beginner
Dangling-Else, Top-Down Parsing, CFG
Background
The dangling-else ambiguity is a classic real-world problem that affects C, Java, and many other
languages. Understanding how it arises from an ambiguous grammar and how unambiguous rewriting
resolves it is a key learning outcome of the parsing unit. A visual side-by-side parse tree comparison
makes the impact of ambiguity concrete.
Problem Statement
Build a tool that:
16. Accepts an if-else grammar in standard BNF form
17. Detects whether the grammar is ambiguous (specifically dangling-else)
18. Automatically rewrites the grammar to be unambiguous using matched/unmatched statement
technique
19. Accepts a test program with nested if-else statements
20. Shows two parse trees for the ambiguous case and one definitive tree for the resolved case
21. Explains at each step why the unambiguous grammar chooses the "most-recent else" rule
Deliverable
A grammar transformation engine that detects dangling-else ambiguity, rewrites the grammar, and
renders before/after parse trees with annotated explanations for at least 5 test programs.
Judging Criteria
1. Correct ambiguity detection algorithm
2. Valid unambiguous grammar output
3. Visual clarity of side-by-side parse trees
4. Quality of step-by-step explanation
5. Test suite coverage
Recommended Technology Stack
Any language. Python + Graphviz recommended for tree rendering.
Bonus Challenge (+10 marks)
Extend to detect other forms of grammatical ambiguity beyond dangling-else.
PS-05 — LRLearn — Step-by-Step LR Parser Simulator
Unit: Unit III: Bottom-Up Parsing Syllabus Topics: SLR, CLR(1), LALR, Shift- Difficulty: Advanced
Reduce, Handle Pruning, LR Items
Background
Bottom-up LR parsing is the most powerful and widely used parsing technique in production compilers
(GCC, Clang, YACC). However, the construction of LR item sets, GOTO tables, and action tables is
notoriously difficult to learn from static textbook diagrams. A simulator that walks through every shift and
reduce step with full stack visualization is one of the most valuable educational tools a team can build.
Problem Statement
Build an LR parser simulator that:
22. Accepts a context-free grammar from the user
23. Constructs the canonical LR(0) item sets and the GOTO automaton
24. Builds parsing tables for all three variants: SLR(1), CLR(1), and LALR(1)
25. Highlights shift-reduce and reduce-reduce conflicts in the table when they occur
26. Accepts a test string and animates the parse step by step:
• Shows stack contents, remaining input, and action taken at each step
27. Identifies the handle at each reduction and shows how it is pruned from the stack
Deliverable
A full LR parser construction and simulation engine supporting SLR, CLR(1), and LALR(1), with animated
step-by-step parse traces, item set visualization, and conflict detection and reporting.
Judging Criteria
1. Correctness of item set construction and GOTO automaton
2. Accuracy of SLR, CLR, LALR table generation
3. Correct conflict detection and clear reporting
4. Quality of step-by-step parse animation
5. Handles at least 5 diverse test grammars
Recommended Technology Stack
Python recommended for parser engine. Any front-end for animation.
Bonus Challenge (+10 marks)
Add YACC/Bison-style conflict resolution (precedence and associativity directives) and show effect on the
table.
PS-06 — ThreeAddrGen — Source to Three-Address Code Translator
Unit: Units IV & V: Syntax Directed Translation & Syllabus Topics: SDT, S-attributed, L- Difficulty: Medium
Intermediate Code attributed, AST, Three-Address Code, Polish
Notation, Boolean Expressions
Background
Syntax-directed translation bridges parsing and code generation — it is where the compiler first produces
something that resembles executable instructions. Students often learn SDDs and TAC independently
without seeing how they connect. A translator that shows the annotated parse tree alongside the
generated TAC makes this connection visible and memorable.
Problem Statement
Build a compiler front-end that:
28. Accepts C-like source programs (assignments, if-else, while loops, Boolean expressions)
29. Parses the program and constructs an annotated syntax tree (AST)
30. Shows the syntax-directed definition (SDD) annotations:
• Synthesized attributes (S-attributed) for arithmetic expressions
• Inherited attributes (L-attributed) for statement-level translation
31. Generates three-address code for each construct
32. Shows the corresponding Polish (postfix) notation for each expression
33. Handles Boolean expressions with short-circuit evaluation using backpatching
Deliverable
A translator producing annotated ASTs and three-address code for C-like programs, with SDD
annotations displayed at each tree node and backpatching shown for Boolean expressions.
Judging Criteria
1. Correctness of AST construction
2. Valid three-address code for all construct types
3. Correct backpatching for Boolean and flow-of-control
4. Visual quality of annotated AST display
5. Coverage: assignments, if-else, while, Boolean expressions
Recommended Technology Stack
Python (PLY or hand-written parser). Graphviz or [Link] for AST visualization.
Bonus Challenge (+10 marks)
Add translation of array accesses and function calls to TAC.
PS-07 — OptiBlock — Basic Block Optimizer with DAG
Unit: Unit VI: Code Optimization Syllabus Topics: Basic Blocks, Flow Graphs, Difficulty: Advanced
DAG, CSE, Dead Code Elimination, Constant
Folding, Global Data Flow
Background
Code optimization is what separates production compilers from academic ones. Most students never see
how a compiler silently eliminates redundant computations, propagates constants, or removes dead code
— transformations that make programs run 2-5x faster without changing their semantics. A tool that
visualizes the DAG per basic block and shows the before/after impact is both educational and impressive.
Problem Statement
Build a basic block optimizer that:
34. Accepts three-address code as input
35. Identifies basic blocks using the leader algorithm
36. Constructs a Control Flow Graph (CFG) with directed edges between blocks
37. For each basic block, builds a Directed Acyclic Graph (DAG):
• Leaf nodes for input variables and constants
• Interior nodes for operations, shared when the same expression appears twice (CSE)
38. Applies optimizations from the DAG:
a. Common Subexpression Elimination (CSE)
b. Dead Code Elimination (nodes with no live labels)
c. Constant Folding (evaluate constant expressions at compile time)
39. Regenerates optimized TAC from the DAG
40. Produces a metrics report: instructions before/after, CSE hits, constants folded
Deliverable
An optimization engine with DAG visualization per basic block, interactive CFG display, annotated
optimized TAC output, and a metrics dashboard showing quantified improvement.
Judging Criteria
1. Correct basic block identification (leader algorithm)
2. Valid DAG construction with shared nodes for CSE
3. Correctness of all three optimizations
4. Quality of DAG and CFG visualization
5. Metrics accuracy and dashboard clarity
Recommended Technology Stack
Python for optimizer engine. Any visualization library. Optional: web front-end.
Bonus Challenge (+10 marks)
Extend with global data flow analysis — compute GEN/KILL sets and run iterative data flow equations to
find globally available expressions.
PS-08 — TargetGen — Simple Code Generator with Register Allocator
Unit: Unit VII: Code Generation Syllabus Topics: Code Generation, Register Difficulty: Advanced
Allocation, Peephole Optimization, Object
Code, Target Machine
Background
The final mile of a compiler — producing actual machine instructions — is rarely taught with a hands-on
implementation. Students learn the theory of register allocation and peephole optimization but never see
them in action. Building a simple code generator for a hypothetical target machine closes this loop and
completes the full compiler pipeline journey.
Problem Statement
Build a code generator for a simple hypothetical 3-register target machine (R1, R2, R3) that:
41. Accepts three-address code as input
42. Performs register allocation:
• Maintains a register descriptor (which values are in each register)
• Maintains an address descriptor (where each variable's current value lives)
• Spills to memory when all registers are occupied
43. Generates target assembly instructions:
• LOAD, STORE, ADD, SUB, MUL, DIV, MOV, CMP, JMP, JMPZ, JMPGT
44. Applies peephole optimization on the generated code:
• Remove redundant LOAD after STORE to same location
• Remove unreachable instructions after unconditional JMP
• Eliminate identity moves (MOV Ri, Ri)
45. Shows both absolute and relocatable object code forms
46. Displays before/after instruction count from peephole optimization
Deliverable
An end-to-end code generator producing annotated target assembly from TAC, with a register allocation
table, peephole optimizer, object code output, and an instruction count comparison.
Judging Criteria
1. Correctness of register allocation (descriptors maintained accurately)
2. Valid target assembly generation for all TAC instruction types
3. Correctness of peephole optimization patterns
4. Clear display of register and address descriptor states
5. Object code format (absolute vs relocatable) demonstration
Recommended Technology Stack
Python recommended. No external compiler tools required — implement from scratch.
Bonus Challenge (+10 marks)
Implement graph-coloring register allocation and compare with the simple algorithm on the same TAC
input.