[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp

[Andrey Bokhanko]

All,

Let me summarize the discussion so far:

1) It seems everyone agree that libiomp (by whatever name it will be
known) should be default library for -fopenmp option. Yay!
2) Some people are concerned that libomp's readme file doesn't express
its multi-platform nature. As Jim Cownie pointed out, developers who
actually ported the library to non-x86 platforms are most knowledgable
on state of things for each particular platform, and should update
readme file themselves.
3) Some people believe that libiomp is not a proper name anymore and
should be changed. I'm not a library expert, so really don't know.
However, this means that we should flip default library setting ASAP.
Why? Because now "libiomp5" is a user-visible name (one has to use
"-fopenmp=libiomp5" to enable OpenMP in clang) and the sooner it will
become non user-visible, the better. Any objections here?

Andrey


On Thu, Apr 30, 2015 at 4:49 PM, Andrey Bokhanko
<andreybokhanko at gmail.com> wrote:
> All,
>
> I'd like to resurrect the discussion on replacing libgomp with libiomp as
> the default OpenMP runtime library linked with -fopenmp.
>
> For reference, the previous discussion is accessible there:
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461
>
> We are very close to getting *full* OpenMP 3.1 specification supported in
> clang (only one (!) clause is not implemented yet, and the patch is already
> sent for review today: http://reviews.llvm.org/D9370). This implementation
> generates Intel API library calls; thus, it can't be used with libgomp and
> it is simply logical to link a compatible runtime (libiomp) instead.
>
> Last time Chandler objected against doing this, and gave a good (and
> proper!) scolding. Let me quote his objections along with updates on current
> state of things:
>
> - 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.
>
>
> Now it is actively developed by several members of the community. Changes
> are committed in small patches. See "openmp-commits" mailing list
> (http://lists.cs.uiuc.edu/pipermail/openmp-commits/) for details.
>
>
> - 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.
>
>
> Nowadays the traffic, while less than on llvm-dev mailing list
> (understandably so :-)) is far from being "zero". Discussions happen all the
> time. See the list archives for details
> (http://lists.cs.uiuc.edu/pipermail/openmp-dev/).
>
>
> - 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.
>
>
> This is fixed.
>
>
> - 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.
>
>
> The build system is full re-written and now cmake-based. The last remaining
> step (integration into overall llvm build system) is about to be done by any
> day now
> (http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500).
>
>
> - 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!
>
>
> UofHouston contributed a comprehensive test suite:
> http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/.
>
>
> - No part of this library has gone through an LLVM release process either,
> not even as a "new" or "beta" project.
>
>
> The whole library is a part of two last llvm releases: 3.5 and 3.6.
>
>
> Thus, I believe all of Chandler's concerns are resolved, and it is finally a
> good time time to switch to libiomp as default OpenMP library.
>
>
> Anyone who supports this?
>
>
> Anyone who disagrees?
>
>
> Chandler?
>
>
> Yours,
> Andrey Bokhanko
> ==============
> Software Engineer
> Intel Compiler Team
> Intel
>