CS 6120: Advanced Compilers Syllabus

This is a research-oriented PhD course about programming language implementation. The class focuses on hacking, reading papers, and writing blog posts.


Please sign up for the course Zulip. All course communication will happen there (not on email). You will need this magical, Cornell-authenticated invitation link to register for Zulip.

(Zulip is an open-source Slack-like chat tool with a few unique features that make it a good fit for class discussion. Thanks to the Zulip folks for donating a plan for 6120!)

Class Sessions

Check the schedule for each day of class—it will fall into one of two categories:

The Work

There are four kinds of things that make up the coursework for CS 6120.

Implementation Tasks

To reinforce the specific compiler techniques we learn about in class, you will work on implementing them on your own. The usual pattern is that we will come up with the high-level idea and the pseudocode in lessons; your job is to turn it into real, working code and collect empirical evidence that it’s working. Going through the complete implementation will teach you about realities that you cannot get by thinking at a high level.

Testing your implementation is a critical component. Your job is to make a convincing case that your implementation does what you intended it to do: for example, an optimization is supposed to make programs faster, most of the time, and never break any programs. A formal proof of these properties is probably out of scope, so you will need to find some other way to gather evidence. In particular, don’t (just) use existing test cases you find in the Bril git repository, which are never thorough enough. One good tactic can be to use all the benchmarks in the repo, however.

You can work individually or in groups of 2–3 students. When you finish an implementation, do this:

Do all your own work (with your group) on implementation tasks. I have sample implementations for many of the tasks in the 6120 GitHub repository; you may not use this code. Past 6120 students have open-sourced their implementations; you may not use this either. I recommend not looking at my or others’ implementations at all while working on tasks, so you actually learn how to do it—but it’s not hiding if you absolutely need it. You are an adult, presumably, and can control your own impulse to skip the hard work.

Paper Reading & Discussion

Another part of 6120 is reading and discussing research papers. Every time we read a paper (see the schedule), everybody participates in the discussion in two ways: through GitHub Discussions threads before class, and then synchronously in class. For every paper, there will be a Discussions topic; post at least one message there with your thoughts on the paper before the class period with the discussion. Your comment need not be long at all; just a couple of sentences is fine. And it need not be a top-level post; I encourage you to respond to other people’s thoughts on the thread.

For some subset of the papers, you will be the discussion leader! Leaders have three extra responsibilities: monitoring and replying to the asynchronous discussion, moderating and guiding the in-class discussion, and synthesizing some ideas into a blog post after the fact.

At least a week before the discussion day:

During the lead-up to the discussion day:

On the discussion day:

Due one week after the discussion day:


At the end of the course, you’ll do a language implementation research project. This is an open-ended and open-source project that can be on any topic that you can construe as being about compiler hacking. The final product is an experience report on the course blog where you rigorously evaluate the success of your implementation.

You can work individually or in groups of 2–3 people.


The first deadline is the project proposal. Open a GitHub issue answering these three questions, which are a sort of abbreviated form of the Heilmeier catechism:

You should also list the GitHub usernames of everyone in the group. After you send the PR, submit its URL to the “Project Proposal” assignment on CMS.

The instructor will have feedback on how to approach your project.


The main phase, of course, is implementing the thing you said you would implement. I recommend you keep a “lab notebook” to log your thoughts, attempts, and frustrations—this will come in handy for the report you’ll write about the project.

I strongly recommend that you develop your code as an open-source project. Use a publicly-visible version control repository on a host like GitHub, and include an open source license. When you create your repository, comment on your proposal GitHub issue with a link. (If you have a specific objection to open-sourcing your code, that’s OK—include a description of how you’ll share your code privately with me.)


A major part of your project is an empirical evaluation. To design your evaluation strategy, you will need to consider at least these things:

Other questions may be relevant depending on the project you choose. Consider the SIGPLAN empirical evaluation guidelines when you design your methodology.

Experience Report

For the main project deadline, you will write up the project’s outcomes in the form of a post on the course blog. Your writeup should answer these questions in excruciating, exhaustive detail:

As with paper discussions, you can optionally include a video to go along with your blog post.

To submit your report, open a pull request in the course’s GitHub repository to add your post to the blog. In your PR description, please include “closes #N” where N is the issue number for your proposal. The repository README has instructions.


I will grade the four categories of coursework based on a Michelin star system: you should shoot for one star, indicating excellent implementation work, insightful participation, a thoughtful blog post, or a spectacularly successful project. Merely acceptable work will receive no stars, and extraordinary work can receive multiple stars. On CMS, all assignments are out of one point, indicating the number of stars.

Consistently earning a Michelin star will get you an A for the course. Occasional multi-star work yields an A+, and missing stars leads to incrementally lower grades.


Non-PhD Enrollment

CS 6120 is for PhD students. If that doesn’t describe you, you can still apply to take the course. Write short answers to these two questions:

  1. What is CS 6120 about?
  2. Why do you want to take the course?

Submit your responses as a one-page PDF to Adrian via Zulip. Please do this after the first class session, so you have some context about the course, and before the second (i.e., by August 24, 2023). I will approve your application via Zulip, and then you can ask the registration office to enroll you. The registration office would appreciate it if you add yourself to the waitlist before contacting them, but I think this is not strictly necessary.

Academic Integrity

Absolute integrity is expected of all Cornell students in every academic undertaking. The course staff will prosecute violations aggressively.

You are responsible for understanding these policies:

You can also read about the protocol for prosecution of violations.

Everything you turn in must be ether 100% completely your own work or clearly attributed to someone else. You may discuss your work with other students, look for help online, get writing feedback from the instructor, ask your friend to help debug something, or anything else that doesn’t involve someone else doing your work for you. You may not turn in any writing that you did not do yourself or misrepresent existing implementation work as your own.

The projects in this course are open source, and you may use existing code in your implementation—including code written by other students in this course. You must, however, make it clear which code is yours and which code is borrowed from where.

Generative AI

The work you do for CS 6120 consists of writing code and natural language descriptions. To some extent, the new crop of “generative AI” (GAI) tools can do both of these things for you. In this class, you can choose—for every assignment—between two options:

  1. Avoid all GAI tools. Disable GitHub Copilot in your editor, do not ask chatbots any questions related to the assignment, etc. If you choose this option, you have nothing more to do.
  2. Use GAI tools, and include a one-paragraph description of everything you used them for along with your writeup. This paragraph must:
    • Link to exactly which tools you used and describe how you used each of them, for which parts of the work.
    • Give at least one concrete example (e.g., generated code or Q&A output) that you think is particularly illustrative of the “help” you got from the tool.
    • Describe any times when the tool was unhelpful, especially if it was wrong in a particularly hilarious way.
    • Conclude with your current opinion about the strengths and weaknesses of the tools you used for real-world compiler implementation.

Remember that you can pick whether to use GAI tools for every assignment, so using them on one set of tasks doesn’t mean you have to keep using them forever.

Respect in Class

Everyone—the instructor, TAs, and students—must be respectful of everyone else in this class. All communication, in class and online, will be held to a high standard for inclusiveness: it may never target individuals or groups for harassment, and it may not exclude specific groups. That includes everything from outright animosity to the subtle ways we phrase things and even our timing.

For example: do not talk over other people; don’t use male pronouns when you mean to refer to people of all genders; avoid explicit language that has a chance of seeming inappropriate to other people; and don’t let strong emotions get in the way of calm, scientific communication.

If any of the communication in this class doesn’t meet these standards, please don’t escalate it by responding in kind. Instead, contact the instructor as early as possible. If you don’t feel comfortable discussing something directly with the instructor—for example, if the instructor is the problem—please contact the advising office or the department chair.

Special Needs and Wellness

We provide accommodations for disabilities. Students with disabilities can contact Student Disability Services at 607-254-4545 or the instructor for a confidential discussion of their individual needs.

If you experience personal or academic stress or need to talk to someone who can help, contact the instructor or: