MLIRHow to Contribute
Everyone is welcome to contribute to MLIR. There are several ways of getting involved and contributing including reporting bugs, improving documentation and tutorials.
Community Guidelines ¶
Please be mindful of the LLVM Code of Conduct, which pledges to foster an open and welcoming environment.
Contributing code ¶
We don’t accept pull-request on GitHub, instead we use Phabricator. At the moment you need to also join this group to enable build and test of your Phabricator revisions.
Once a patch is approved on Phabricator and pass continuous integration checks, it can be pushed directly to the main branch of the repository.
Using Arcanist ¶
Use Arcanist to send your patches for review. This triggers the continuous build system and preserves the authorship information in case somebody else commits the patch on your behalf.
You can also setup a check as a git hook to prevent accidentally pushing
unformatted commits with:
ln -sf ../../llvm/utils/git/pre-push.py .git/hooks/pre-push
First-time contributors ¶
LLVM follows a policy of granting established contributors direct commit access to the repository. If you make your first contributions to the LLVM infrastructure, you are unlikely to have commit access. In this case, ask the reviewers to commit the change for you after it has been accepted. Once you have demonstrated the ability to write high-quality patches, follow the policy to obtain commit access for yourself.
Note: if you haven’t used Arcanist to send your patch for review, committers don’t have access to your preferred identity for commit messages. Make sure to communicate it to them through available channels or use the git sign-off functionality to make your identity visible in the commit message.
Commit messages ¶
Follow the git conventions for writing a commit message, in particular the first line is the short title of the commit. The title should be followed by an empty line and a longer description. Prefer describing why the change is implemented rather than what it does. The latter can be inferred from the code. This post give examples and more details.
Issue tracking ¶
To report a bug, use the MLIR product on the LLVM bug tracker, try to pick a suitable component for the bug, or leave it in the default.
If you want to contribute, start working through the MLIR codebase, navigate to the “good first issue” issues and start looking through interesting issues. If you decide to start on an issue, leave a comment so that other people know that you’re working on it. If you want to help out, but not alone, use the issue comment thread to coordinate.
Contribution guidelines and standards ¶
- Read the developer guide.
- Ensure that you use the correct license. Examples are provided below.
- Include tests when you contribute new features, as they help to a) prove that your code works correctly, and b) guard against future breaking changes to lower the maintenance cost.
- Bug fixes also generally require tests, because the presence of bugs usually indicates insufficient test coverage.
License ¶
Include a license at the top of new files.