Contributing a new target to LLVM

Hi LLVM and CLang Devs,

At the moment my company (Movidius) is considering contributing the changes we have made to LLVM and CLang in order to support our proprietary processor, and I would like to seek advice on how best to approach doing this? I am pretty sure that there are coding guidelines and conventions that we should be following but have not followed over the course of the last few years, and we will have to go through the process of preparing the sources so that they are suitable for pushing back to the LLVM and CLang community, though I expect that as a small team of 2 developers this is likely to take us several months.

Are there any existing documents that I should read to help us prepare our code so that it might be acceptable to the LLVM (and CLang) communities? What guidelines are there for contributors submitting new targets to LLVM, how they should maintain them in the future, and how to ensure that other targets are not negatively impacted by the addition?

Thanks in advance,

Martin

Hi LLVM and CLang Devs,

At the moment my company (Movidius) is considering contributing the changes
we have made to LLVM and CLang in order to support our proprietary
processor, and I would like to seek advice on how best to approach doing
this? I am pretty sure that there are coding guidelines and conventions
that we should be following but have not followed over the course of the
last few years, and we will have to go through the process of preparing the
sources so that they are suitable for pushing back to the LLVM and CLang
community, though I expect that as a small team of 2 developers this is
likely to take us several months.

Are you able to give more information about the processor? Is it a CPU,
GPU, DSP?

Are there any existing documents that I should read to help us prepare our
code so that it might be acceptable to the LLVM (and CLang) communities?
What guidelines are there for contributors submitting new targets to LLVM,
how they should maintain them in the future, and how to ensure that other
targets are not negatively impacted by the addition?

Here are a few suggestions for starting the process of getting your
backend upstream.

- Publish your code somewhere public (github, bitbucket, etc.) as soon as you
can.

- Adopt an 'upstream' development model, which means moving your patch
  review process to the public mailing lists and committing changes
  directly to LLVM ToT (or your temporary public repo). Whether you
  commit to internal trees first and then commit upstream or the other
  way around is up to you, but the point is that your interaction with
  LLVM ToT should not be monthly patch bombs.

- Make sure you comply with the coding standards
  (http://llvm.org/docs/CodingStandards.html)

- If you have changes to core libraries, break them up into small
  self-contained patches and send them to the mailing lists.

- When targets are first added to LLVM, they are built using the
  experimental target options. Make this change internally to make it
  easier to merge your code.

- As you prepare the code, keep the community in the loop on the
  progress (this is where it helps to have a public repo).

This is not a complete list, but hopefully it will help get you started.

-Tom

Welcome! A few additional suggestions to Tom's already excellent
suggestions...

Here are a few suggestions for starting the process of getting your
backend upstream.

- Publish your code somewhere public (github, bitbucket, etc.) as soon as
you
can.

I would also recommend making a Phabricator review available for folks to
glance at the code in that format.

- Adopt an 'upstream' development model, which means moving your patch
  review process to the public mailing lists and committing changes
  directly to LLVM ToT (or your temporary public repo). Whether you
  commit to internal trees first and then commit upstream or the other
  way around is up to you, but the point is that your interaction with
  LLVM ToT should not be monthly patch bombs.

- Make sure you comply with the coding standards
  (http://llvm.org/docs/CodingStandards.html)

In particular, using clang-format will likely help with many of these
issues.

- If you have changes to core libraries, break them up into small
  self-contained patches and send them to the mailing lists.

Absolutely.

- When targets are first added to LLVM, they are built using the
  experimental target options. Make this change internally to make it
  easier to merge your code.

- As you prepare the code, keep the community in the loop on the
  progress (this is where it helps to have a public repo).

This is not a complete list, but hopefully it will help get you started.

It may also be helpful to look at the recently added BPF backend and the
process it followed.