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

[Andrey Bokhanko]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150430/f13af52a/attachment.html>