<div dir="ltr">Alp,<div> My take on this is that we have a chicken and the egg situation here. As long as the</div><div>clang-omp changes haven't been merged into clang trunk, we will be unable to switch</div><div>the default of -fopenmp from -liomp5. So once the clang-omp merge is well underway, </div>
<div>interest in integrating the openmp component into the existing build machinery will</div><div>rapidly pick up.</div><div> Jack</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 10:39 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the summary Andrey.<br>
<br>
The underlying problem For the OpenMP *runtime* is really lack of visibility and sidelining on the openmp-dev list.<br>
<br>
It's absolutely critical to close down the low-volume openmp-dev list and fold the subscribers into one of the more active mailing lists, either llvm-dev or cfe-dev.<br>
<br>
Until that's done the patches won't get review from the mainstream LLVM developer community, build system experts won't join in etc.<br>
<br>
Alp.<div><div class="h5"><br>
<br>
<br>
<br>
On 29/05/2014 16:46, Andrey Bokhanko wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
All,<br>
<br>
To clarify, what I meant is getting OMP runtime library (not clang-omp branch!) as a part of 3.5 release. I specifically referred to this thread: <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/thread.html#73025" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/llvmdev/2014-May/<u></u>thread.html#73025</a> started by Jack. I thought he means libiomp when saying "openmp support" -- apparently, I was mistaken. Hence the confusion.<br>
<br>
After so many talks with Chandler, I know very well that upstreaming full OpenMP support is a long way to go. :-)<br>
<br>
Also, the whole desire to put the library into 3.5 release is a responce to the criticism expressed by Chandler in this message: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/099477.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/cfe-commits/Week-of-<u></u>Mon-20140217/099477.html</a>.<br>
<br>
While we are on the topic, let me update on some other things happening in responce to other issues highlighted by Chandler:<br>
<br>
- 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>
<br>
<br>
- There has been essentially *zero* discussion with the rest of the clang<br>
or llvm community about this library. There are separate mailing lists<br>
which have nearly no traffic since the code drop.<br>
<br>
Take a look at this month's messages: <a href="http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-May/thread.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/openmp-dev/2014-May/<u></u>thread.html</a>. In general, as more people get interested, more traffic became generated. It's a chicken and egg problem...<br>
<br>
- There has been no effort to make this library even work properly with<br>
Clang as a host compiler. See the copious notes that only Clang 3.3 is<br>
supported, and that not full featured.<br>
<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/<u></u>builders/libiomp5-gcc-x86_64-<u></u>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/<u></u>builders/libiomp5-clang-x86_<u></u>64-linux-debian</a><br>
<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>
<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/<u></u>pipermail/openmp-commits/2014-<u></u>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>
<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? :-)<br>
<br>
Andrey<br>
<br>
<br>
<br></div></div><div class="">
On Thu, May 29, 2014 at 2:19 AM, Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.<u></u>com</a> <mailto:<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@<u></u>gmail.com</a>>> wrote:<br>
<br>
Andrey Bokhanko expressed interest in getting the clang-omp<br>
merge done in time for the 3.5 release but wants guidance on the<br>
process. I suggested starting with the creation a new clang-omp<br>
branch upstream rebased on clang trunk for generation of merge<br>
patch. Unfortunately merging the current changes from the<br>
clang-omp (based on clang 3.4) to a clang-omp (based on clang<br>
trunk) looks very difficult as selective patches have been<br>
committed into clang trunk from clang-omp and don't appear to have<br>
been kept synchronized with the current changes from upstream.<br>
Does anyone know if these new files from previous commits out of<br>
clang-omp contain any local changes which haven't been back ported<br>
to clang-omp? It would seem that postponing this merge will just<br>
make the process harder as time goes on if selective merges from<br>
clang-omp into clang trunk continue in the interim. Hopefully<br>
the folks who did the original selective commits would help<br>
detangle this mess.<br>
Jack<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br></div>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> <mailto:<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><div class=""><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</div></blockquote>
<br><div class="HOEnZb"><div class="h5">
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div><br></div>