Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
84 lines (66 loc) · 4.84 KB

CONTRIBUTING.md

File metadata and controls

84 lines (66 loc) · 4.84 KB

Contributing to rocMLIR

Thanks for your interest in contributing.

Reporting Issues

Use GitHub Issues to report bugs or request features. Include a clear description, reproduction steps, and your environment: OS, ROCm version, GPU architecture (e.g. gfx942, gfx950, gfx1100).

Pull Request Workflow

  1. Get the source and create a branch from develop. External contributors should fork the repository first; AMD contributors with write access can clone the upstream directly: 
    # Replace <owner> with your fork's owner, or `ROCm` if you have write access.
git clone https://github.com/<owner>/rocMLIR.git
cd rocMLIR
# AMD contributors: name the branch `users/<username>/<description>` or
# `<jira-id>-<description>` (e.g. AIROCMLIR-123-fix-attention-mask).
# Forks: any branch name works on your side; this convention only applies in
# the upstream repo.
git checkout -b users/<username>/<description>
  2. Make your change. Add tests under mlir/test/ and update docs if behavior changes.
  3. Format your C/C++ and TableGen (.td) changes with clang-format (uses the repo's .clang-format): 
    # Replace `origin/develop` with `upstream/develop` if you've forked
# and named the `ROCm/rocMLIR` remote `upstream` -- the baseline
# must be the latest upstream `develop`, not your fork's.
git clang-format origin/develop
    The CI clang-format job runs git clang-format --diff origin/develop (CI's checkout always names the ROCm/rocMLIR remote origin) and fails on any non-empty diff. The repo's .clang-format uses TableGen-specific options (TableGenBreakInsideDAGArg, TableGenBreakingDAGArgOperators) introduced in clang-format 19, so a clang-format binary of version 19 or newer is required (20 matches CI; install via apt install clang-format-20 or from apt.llvm.org). Point git clang-format at it with git clang-format --binary clang-format-20 origin/develop if it's not your default.
  4. Build and run the test suite locally: 
    mkdir -p build && cd build
cmake -G Ninja .. -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DCMAKE_CXX_COMPILER=/opt/rocm/llvm/bin/clang++
ninja check-rocmlir
  5. Open a PR against develop. Describe what changed and why; link any related issue.
  6. Ensure CI passes and request review from the relevant CODEOWNERS.

By opening a PR, you agree your contribution is licensed under the terms in LICENSE.

Coding Standards and Review Checklist

See docs/PR_REVIEW_CHECKLIST.md for the full Critical / Major / Minor PR review checklist, the license-header template, and the list of upstream references (LLVM Coding Standards, MLIR Developer Guide, .clang-format, .clang-tidy). Reviewers -- human and automated -- categorize findings against the tiers there.

In short: MLIR's naming convention deviates from LLVM in one place -- variables, parameters, and class members use camelBack (lowerCamelCase), not the traditional Capitalized form. Functions remain camelBack; classes, enums, and unions are PascalCase. Style is enforced via .clang-format (LLVM base style) and .clang-tidy; matching the CI clang-format job locally with git clang-format --diff origin/develop (or upstream/develop if you've forked; see the remote-name note in Step 3 of the workflow above) is the minimum expectation before opening a PR.

Python helpers (under mlir/utils/performance/ and elsewhere) follow yapf and flake8. Format with yapf -i <files> and lint with flake8 <files> before committing changes there.

AI Tool Use

This project follows the LLVM AI Tool Use Policy. In short:

  • You may use any tool (LLMs, copilots, code-gen agents, etc.) to produce contributions, but there must be a human in the loop: read and understand everything you submit, and be ready to answer questions about it during review.
  • Submitting unreviewed tool output that shifts the review burden onto maintainers (an "extractive contribution") is not acceptable.
  • Be transparent. If a contribution contains a substantial amount of tool-generated content, note it in the PR description or commit message (an Assisted-by: trailer is the recommended form).
  • Automated agents that open PRs, post review comments, or otherwise act in this repository without human approval are not allowed.

See the linked policy for the full rationale and details.

External Contributors

This repo is part of the ROCm org. Non-AMD contributors need admin approval before being added as collaborators and must follow AMD's open-source contribution guidelines.

Security

For security issues, do not open a public issue -- see SECURITY.md.