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
_______________________________________________________________
Martin J. O'Riordan Email:
<mailto:Martin.ORiordan at movidius.com> Martin.ORiordan at movidius.com
Compiler Development Web: <http://www.movidius.com>
www.movidius.com
Movidius Ltd. Skype: moviMartinO
1st Floor, O'Connell Bridge House, d'Olier Street, Dublin 2, Ireland
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/a3f216d5/attachment.html>
On Fri, Mar 27, 2015 at 03:00:30PM -0000, Martin J. O'Riordan wrote:> 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> > Thanks in advance, > > > > Martin > > _______________________________________________________________ > > Martin J. O'Riordan Email: > <mailto:Martin.ORiordan at movidius.com> Martin.ORiordan at movidius.com > > Compiler Development Web: <http://www.movidius.com> > www.movidius.com > > Movidius Ltd. Skype: moviMartinO > > 1st Floor, O'Connell Bridge House, d'Olier Street, Dublin 2, Ireland > > >> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Welcome! A few additional suggestions to Tom's already excellent suggestions... On Fri, Mar 27, 2015 at 8:51 AM, Tom Stellard <tom at stellard.net> wrote:> > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/43377c98/attachment.html>