<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 29, 2014 at 6:46 AM, Andrey Bokhanko <span dir="ltr"><<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">While we are on the topic, let me update on some other things happening in responce to other issues highlighted by Chandler:<br>
</div></blockquote><div><br></div><div>I just wanted to say, I am very happy to see progress starting here. =] All of my comments below are meant to help the effort move faster and deal better with the LLVM project.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">- This library is not being developed as an active part of the LLVM<br>community, even if it is checked into SVN as part of the LLVM project and<br>
under its license. See r197914 where there is a code drop of many months<br>worth of development with *no* change log, attribution, information, or<br>other participation in any part of the community.<br><br>This is changing, and many developers joining the whole OpenMP in clang support effort. I can say that Michael Wong and many of his colleagues from IBM are involved; Eric Stotzer and his colleagues from TI are involved; Barbara Chapman and her group from UofHouston is involved; Guansong Zhang from AMD is involved. Obviously, Hal Finkel, Chris Bergstrom, Steve Noonan and many others continue to be actively involved as well.<br>
<br>Take a look at the recent activity in openmp-dev mailing list. More to come.<br></div></blockquote><div><br></div><div>Pretty happy about this, and looking forward to more. Some things that would be helpful (IMO, others may disagree) to start looking into how/when to adopt or integrate:</div>
<div><br></div><div>- Start more closely following the LLVM developer policy around code review and small, incremental patches and development.</div><div> - Maybe use code review tools like Phabricator? Dunno what would be needed to make this work well, probably some stuff...</div>
<div>- Check that the codebase compiles with the same host toolchain baseline as the rest of the LLVM project[1]</div><div>- Maybe work out a plan toward generally conforming with the coding standards[2] where applicable?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>It is buildable with clang now. Moreover, regular buildbots, with both gcc and clang, are running:<br>
<br><a href="http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian" target="_blank">http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian</a><br><a href="http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian" target="_blank">http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian</a></div>
</blockquote><div><br></div><div>Just want to say, this in particular is fantastic.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<br>- The build system is totally disjoint from LLVM's, in fact it is an<br>entirely custom Perl build system that is unlike anything in use by the<br>LLVM project.<br><br>We started to work on improving build system. Stay tuned.<br>
</div></blockquote><div><br></div><div>Very cool. I would look closely at the compiler-rt and libc++ CMake builds. Hopefully useful.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<br>- There are *zero tests* in the open source repository!!!! This is even<br>called out in the original submission and on the primary website. We simply<br>*cannot* ship and link against a runtime library which has no tests!<br>
<br>University of Houston contributed OpenUH test suite: <a href="http://lists.cs.uiuc.edu/pipermail/openmp-commits/2014-May/000019.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/openmp-commits/2014-May/000019.html</a>. Sunita Chandrasekaran from the University works on integrating this suite into LLVM test system.<br>
<br>BTW, any advice with how to approach this would be *much* appreciated!<br></div></blockquote><div><br></div><div>I think the right way to go is something along the lines of the ASan (in compiler-rt) lit tests, but maybe others have a better idea. I agree that testing here is hard.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>- No part of this library has gone through an LLVM release process either,<br>not even as a "new" or "beta" project.<br>
<br>Aha! So, you support inclusion of openmp (library, not compiler) in 3.5 as well? :-)</div></blockquote></div><br>Hehe, I see what you did there.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I do genuinely support it going through the release process, but I think that there are two things that need to be pretty solid first:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">1) the build system work probably needs to be pretty solid. i'd be happy with support on par with compiler-rt or libc++ in CMake...</div><div class="gmail_extra">
2) the test suite needs to be at least reasonably well integrated so release testers actually hit it and exercise the code</div><div class="gmail_extra">3) we need a good switch in Clang to use iomp (I know you or someone on the patch thread worked on this, did it land? if so, done!)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Maybe others have other thoughts, but I think those three are my key ones.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anyways, thanks for the clarification and all the hard work on this stuff.</div>
</div>