MLIR for CPU and WebGPU Code Generation

ISEF Category: Systems Software

Subcategory: Languages and Operating Systems  ·  Difficulty: Advanced  ·  Setup: University Lab  ·  Time: Full Year

The Hook

What if one program could run well on a laptop CPU and a WebGPU shader without you rewriting it twice? That is a compiler problem, not a coding trick. The same idea can reveal how modern software decides where work should happen. You can test that choice with image filters and small matrix multiplication.

What Is It?

This project sits in compiler design. A compiler is software that translates code into a form a computer can run. Your focus is an intermediate representation, or IR, which is a middle step between source code and machine code. Think of IR like a universal translator inside the compiler. It gives the compiler one clean place to analyze the program before sending it to different targets.

The unusual part here is the target flexibility. Your IR would let the same source program map to both a CPU and a WebGPU shader without extra annotations from the programmer. WebGPU is the browser-friendly graphics and compute API that can also do general math work. The research question is whether one shared representation can keep enough information to generate good code for both targets. You can test that by comparing correctness, speed, and code quality on workloads like image filters and small matrix multiply.

Why This Is a Good Topic

This is a strong science fair topic because you can measure real output, not opinions. You can compare runtime, code size, and performance across targets, then ask whether one IR really helps the compiler make better decisions. The project connects to real problems in browsers, graphics, and portable computing. You will also learn how compilers, parallel execution, and benchmarking fit together.

Research Questions

• How does a shared intermediate representation affect runtime on CPU versus WebGPU targets?
• What is the effect of removing programmer annotations on code generation quality?
• Does the new IR preserve correctness across image filter workloads and small matrix multiplication?
• To what extent do different optimization passes change performance on CPU and WebGPU backends?
• Which workload shows the largest gap between CPU and WebGPU code produced from the same IR?
• How does compile time change when one IR must support two execution targets?

Basic Materials

• Laptop or desktop computer with a modern browser.
• A machine with a CPU that supports local benchmarking.
• A second device or browser profile for repeatability checks.
• Python installed for data processing and plotting.
• Git for version control.
• A code editor such as VS Code.
• Access to MLIR source code and build instructions.
• Benchmark inputs for image filters and small matrix multiplication.
• A spreadsheet or notebook for recording timings and outputs.

Advanced Materials

• University workstation or lab machine with build tools for MLIR.
• A GPU that supports WebGPU or a browser with stable WebGPU support.
• Compiler development tools such as clang, cmake, and ninja.
• Profiling tools for CPU timing and memory use.
• A test suite for compiler correctness checks.
• Image datasets or synthetic image inputs for filter benchmarking.
• Matrix test cases across multiple sizes and data types.
• Optional continuous integration access for repeated builds and tests.

Software & Tools

• MLIR: Provides the compiler infrastructure for building and testing the intermediate representation.
• Python: Cleans benchmark data, checks outputs, and makes graphs.
• Jupyter Notebook: Helps you compare runs and document analysis in one place.
• ImageJ: Measures output differences for image filter benchmarks.
• GNU Octave: Lets you test small matrix multiplication cases and compare numerical results.

Experiment Steps

1. Define the exact compiler question you want to answer, then pick one source language pattern and two targets.
2. Choose benchmark families that stress different parts of the compiler, such as image kernels and small matrix multiplication.
3. Decide what your intermediate representation must preserve so both targets can generate correct code.
4. Plan a fairness framework for benchmarking, including the same inputs, the same build settings, and the same correctness checks.
5. Design the analysis you will use to compare performance, such as speedup, compile time, and output error.
6. Build a validation plan that catches cases where one backend works but the other changes numerical behavior.

Common Pitfalls

• Comparing CPU and WebGPU runs without matching input sizes, which makes the timing data unfair.
• Changing too many compiler passes at once, which makes it hard to tell what improved performance.
• Measuring only speed and ignoring correctness, which can hide wrong code generation.
• Using image filters that are too simple, which can make both targets look similar and weakens the result.
• Testing one matrix size only, which can hide cases where the new IR fails to scale.

What Makes This Competitive

A strong version of this project does more than show that code runs. You would need careful benchmarking, strict correctness checks, and a clear explanation of why the IR helps both targets. A better entry might compare several optimization strategies, or test whether the same design works across more than one workload family. Strong statistical analysis and a clean compiler evaluation story would raise the quality fast.

Project Variations

• Compare the same IR on grayscale image filters versus edge-detection filters to see whether data flow complexity changes backend performance.
• Test whether the IR handles matrix multiplication in row-major and column-major layouts with equal quality.
• Measure how code generation changes when you add one extra backend target, such as CPU, WebGPU, and a third scalar fallback path.

Learn More

• MIT OpenCourseWare: Search for compiler design and programming languages courses that explain intermediate representations and optimization passes.
• MLIR Documentation: Read the official project docs to learn how dialects, passes, and lowering work.
• Google WebGPU Spec and Guides: Use the official WebGPU materials to understand the execution model and shader constraints.
• LLVM Project: Explore the compiler infrastructure that MLIR connects to for code generation and optimization.
• PubMed Central: Search for peer-reviewed papers on compiler performance evaluation, IR design, and heterogeneous computing.