Contribution Philosophy

To keep the LLZK codebase maintainable and approachable, we follow these guiding principles for all contributions:

Testing, testing, testing. Every PR should come with thorough tests (especially lit tests) that demonstrate the behavior of the new feature/changes. Good tests make your PR easier to review and maintain, as tests serve as both demonstrations of correctness and working examples.
Document thoroughly. New features should be documented clearly (e.g., with TableGen docs for passes). Documentation should describe both the intent and the operation of the feature.
Small PRs are better. Large PRs are difficult to review. We would prefer to review a sequence of smaller PRs that gradually extend functionality rather than a single large PR. For example, start with a PR handling the simplest cases (with more complex cases as "TODOs"), and then extend support in subsequent PRs.
Readable over clever. Code should be simple and understandable. If you must choose between a highly optimized solution and a readable one, choose readability. Optimizations can always come later.
Avoid overengineering. Avoid adding generalized abstractions until they're needed. For example, avoid templates or callback-based designs if only one specialization or behavior exists. Over-generalizing makes code harder to understand and maintain.

Getting started

Issues

Create a new issue

If you spot a problem, encounter a bug, or want to request a new feature, first search for an existing issue. Please contribute to an existing issue when possible instead of opening a duplicate.

If a related issue does not exist, open a new issue using the relevant issue form. A new issue must clearly describe and motivate the bug or feature, including its impact or use case, expected behavior, and enough detail for a maintainer to evaluate it.

New issues begin with the under review label. This means the proposal is still being evaluated or refined. A maintainer may ask for more information, narrow the scope, suggest an alternative, or decline the proposal. Do not submit a PR while an issue is still under review because it will be closed.

A maintainer will replace that label with approved when the issue is sufficiently motivated, appropriately scoped, and suitable for implementation. Approval does not assign the issue to a contributor or guarantee that a resulting PR will be merged.

Solve an issue

External contributors should start by scanning our existing issues for one that interests them. Issues labeled approved are ready for implementation; issues also labeled good first issue are intended to be approachable for newcomers. You can narrow the search using labels as filters.

As a general rule, we do not assign issues. Before starting work, comment on the issue to share your intended approach and coordinate with other contributors. Every external contribution must resolve one or more existing issues, and those issues must be marked approved before implementation begins.

Make Changes

Fork the repository.
- Using GitHub Desktop:
  - Getting started with GitHub Desktop will guide you through setting up Desktop.
  - Once Desktop is set up, you can use it to fork the repo!
- Using the command line:
  - Fork the repo so that you can make your changes without affecting the original project until you're ready to merge them.
Install or update LLZK development dependencies. For more information, see the development guide
Create a working branch and start with your changes!

Generate FileCheck directives

The scripts/generate-test-checks.py utility generates heuristic FileCheck directives from printed MLIR or LLZK IR. Use it to bootstrap checks, then review them against the behavior the test is intended to cover:

llzk-opt input.llzk --canonicalize | scripts/generate-test-checks.py

When --source is provided, every line matching --source_delim_regex begins a source segment; the default pattern is func @, which does not match LLZK's function.def spelling. Choose an anchored pattern that matches the actual source segments. For split-input tests, use the split boundaries or generate from a temporary file containing only the relevant input chunks. Use -i/--inplace only after checking the generated output. In-place mode requires --source, cannot be combined with --output, and refuses to modify a source whose supplied path or resolved target is in a dirty Git worktree, including untracked files. Use --allow-dirty only when updating generated directives in a dirty worktree is intentional. In-place output must contain one check block for each source segment; otherwise, the script exits without modifying the source. In-place mode writes the complete result to a temporary file beside the resolved source, copies its permission bits, and then replaces the resolved source file; a source symlink remains intact. In-place generation or replacement failures leave the source unchanged.

Run the utility's unit tests with python3 -m unittest scripts/generate-test-checks.py -v.

Source updates replace recognized FileCheck directives only for the selected prefix and preserve unrelated source text and comments. The generated checks are not authoritative: verify that they cover the relevant behavior, and retain complete transformed output for transformation tests.

LLZK tests should have // RUN: on the first line(s) followed by a blank line. Any necessary check lines shold follow the input IR. In a multi-test file each individual test should have a brief description before the test input and any necessary check lines after the input but before the next // ----- separator. Keep the generated indentation and SSA substitutions, with no blank lines or prose inside a check block. These layout adjustments must not omit any transformed output.

Commit your update

Commit the changes once you are happy with them. Remember that all code must pass a format check before it can be merged, so consider running clang format before pushing your commits. For more information, see the development workflow section.

Pull Request

When you are finished with the changes, create a pull request, also known as a PR. External PRs must link to the approved issue or issues they resolve.

Best Practices Checklist

Before submitting your PR, ensure you have:

Added lit and/or unit tests covering all relevant cases.

Updated TableGen and/or other documentation to describe new features.

Added a changelog. All PRs require a changelog describing what user-level changes have been made in the PR. To create a template changelog, run create-changelog from the nix shell.

Linked the PR to the existing issue or issues it resolves. For external contributions, each issue must be marked approved.

Disclosed whether AI tools contributed to the PR. If they did, identified the tools, described how they contributed, and explained how their output was verified.

Enabled the checkbox to allow maintainer edits so the branch can be updated for a merge.

Pull Request Review

Once you submit your PR, a maintainer will first review its linked issue(s). We may defer implementation review until every issue addressed by an external PR is marked approved. If the motivation or scope is unclear, we will continue that discussion on the issue before reviewing the implementation.

After the linked issues are approved, a maintainer will review the PR. We may ask questions or request additional information.

We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
As you update your PR and apply changes, mark each conversation as resolved.
If you run into any merge issues, checkout this git tutorial to help you resolve merge conflicts and other issues.

Your PR is merged!

Congratulations! The LLZK team thanks you.

Once your PR is merged, your contributions will be publicly available in the LLZK-lib repository.

Previous	Next
Tool Guides	LLZK IR Dialects

Table of Contents