Requirements for getting a new backend mainlined?

Hi, all!

I am currently working on a backend for the Parallax Propeller 2, and would like to know what the requirements are for a new backend to get mainlined into LLVM, and also get any general advice for writing a backend so that I don't have to go back and change a bunch of things later when I'm ready to submit a patch.

I'm new to working with LLVM, so any advice outside what I just asked for is also appreciated.

Thanks, Braden.

Here’s a starting point, at least: https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target

HI Braden,

I’m also working pretty hard recently on upstreaming Motorola M68k backend to LLVM [1], and the works are wrapping up so I might can give some advices

I think the first thing you need to do is showing to this community that it is not a toy backend and many people (users) are relying on the target architecture.

Regarding the technical and code reviewing part. In addition to the developer policy page posted by David, I would like to highlight some points:

  1. Usually a new target will enter LLVM as an experimental target first (it will not be build by default unless designated by the LLVM_EXPERIMENTAL_TARGETS_TO_BUILD cmake variable) before becoming an official one.

  2. Split all changes into multiple patches, in which each of them is (more or less) grouping similar functionalities. And most important of all, each patch should be buildable by itself. You can take a look on how I split M68k’s patches.

  3. Following up (2), it would be great to commit all patches at once after all of them are approved.

  4. IIUC, your target architecture (Propeller 2) is a less known ISA. As a reviewer, personally I would like to see comments in the files (usually .td files) explaining some of the architectures details (e.g. addressing modes, special behaviors, uncommon operations) that gives reviewers some gravities of how this architecture looks like.

  5. You probably have known — follow LLVM’s coding style and some programming guidelines, like avoid using data structure ABC under XYZ scenarios. For the former, just run clang-format-diff before submitting patches for review. The latter is in this [2] page.

  6. Help reviewing other backends’ patches as well. Since it’s most likely patches in your target are reviewed by maintainers from other backends.

  7. Last but not the least, assign a code owner. Code owner is obligated to review patches in his/her “mission area”, if it has not been reviewed by others. Also, targets that are inactively maintained will be removed from LLVM.

Hope these tips help :slight_smile:

Best,
-Min

[1] First patch in the series of 8: https://reviews.llvm.org/D88385 . Click on “Stack” tab in the “Revision Contents” section to see rest of the patches

[2] https://llvm.org/docs/CodingStandards.html Actually this page also includes coding styles.