[cfe-dev] moving the clang-omp merge along

[Andrey Bokhanko]

All,

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:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/thread.html#73025
started by Jack. I thought he means libiomp when saying "openmp support" --
apparently, I was mistaken. Hence the confusion.

After so many talks with Chandler, I know very well that upstreaming full
OpenMP support is a long way to go. :-)

Also, the whole desire to put the library into 3.5 release is a responce to
the criticism expressed by Chandler in this message:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/099477.html
.

While we are on the topic, let me update on some other things happening in
responce to other issues highlighted by Chandler:

- This library is not being developed as an active part of the LLVM
community, even if it is checked into SVN as part of the LLVM project and
under its license. See r197914 where there is a code drop of many months
worth of development with *no* change log, attribution, information, or
other participation in any part of the community.

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.

Take a look at the recent activity in openmp-dev mailing list. More to come.


- There has been essentially *zero* discussion with the rest of the clang
or llvm community about this library. There are separate mailing lists
which have nearly no traffic since the code drop.

Take a look at this month's messages:
http://lists.cs.uiuc.edu/pipermail/openmp-dev/2014-May/thread.html. In
general, as more people get interested, more traffic became generated. It's
a chicken and egg problem...

- There has been no effort to make this library even work properly with
Clang as a host compiler. See the copious notes that only Clang 3.3 is
supported, and that not full featured.

It is buildable with clang now. Moreover, regular buildbots, with both gcc
and clang, are running:

http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian
http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian

- The build system is totally disjoint from LLVM's, in fact it is an
entirely custom Perl build system that is unlike anything in use by the
LLVM project.

We started to work on improving build system. Stay tuned.

- There are *zero tests* in the open source repository!!!! This is even
called out in the original submission and on the primary website. We simply
*cannot* ship and link against a runtime library which has no tests!

University of Houston contributed OpenUH test suite:
http://lists.cs.uiuc.edu/pipermail/openmp-commits/2014-May/000019.html.
Sunita Chandrasekaran from the University works on integrating this suite
into LLVM test system.

BTW, any advice with how to approach this would be *much* appreciated!

- No part of this library has gone through an LLVM release process either,
not even as a "new" or "beta" project.

Aha! So, you support inclusion of openmp (library, not compiler) in 3.5 as
well? :-)

Andrey



On Thu, May 29, 2014 at 2:19 AM, Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:

>      Andrey Bokhanko expressed interest in getting the clang-omp
> merge done in time for the 3.5 release but wants guidance on the process. I
> suggested starting with the creation a new clang-omp branch upstream
> rebased on clang trunk  for generation of merge patch. Unfortunately
> merging the  current changes from the clang-omp (based on clang 3.4) to a
> clang-omp (based on clang trunk)  looks very difficult as selective patches
> have been committed into clang trunk from clang-omp and don't appear to
> have been kept synchronized with the current changes from upstream. Does
> anyone know if these new files from previous commits out of clang-omp
> contain any local changes which haven't been back ported to clang-omp? It
> would seem that postponing this merge will just make the process harder as
> time goes on if selective merges from clang-omp into clang trunk continue
> in the interim. Hopefully the folks who did the original selective commits
> would help detangle this mess.
>            Jack
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140529/f0d1442a/attachment.html>