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

Andrey Bokhanko
2015-05-01T08:13:20Z

Jack,

Thanks for running the test suite!

I wonder how a *single* test passed with libgomp, given that no real OMP
runtime calls are generated if clang targets libgomp... My educated guess
is that compiler simply ignores all OMP pragmas, a test still compiles and
runs correctly (which is a property of OMP specification) and the test says
"oh! omp parallel for is working just fine!".

Andrey


On Thu, Apr 30, 2015 at 5:23 PM, Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:

>      The current test suite status on x86_64-apple-darwin14, with the
> proposed patch from
>
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128219.html
> applied to current cfe trunk, is quite respectable....
>
> Summary:
> S Number of tested Open MP constructs: 62
> S Number of used tests:                123
> S Number of failed tests:              16
> S Number of successful tests:          107
> S + from this were verified:           106
>
> Normal tests:
> N Number of failed tests:              8
> N + from this fail compilation:        1
> N + from this timed out                0
> N Number of successful tests:          54
> N + from this were verified:           54
>
> Orphaned tests:
> O Number of failed tests:              8
> O + from this fail compilation:        0
> O + from this timed out                0
> O Number of successful tests:          53
> O + from this were verified:           52
>
> for 'make ctest' using "-fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5
> -L/sw/opt/llvm-3.7.0/lib -lm -O3". Whereas for libgomp, the results
are
> pitiful....
>
> Summary:
> S Number of tested Open MP constructs: 62
> S Number of used tests:                123
> S Number of failed tests:              30
> S Number of successful tests:          93
> S + from this were verified:           12
>
> Normal tests:
> N Number of failed tests:              15
> N + from this fail compilation:        0
> N + from this timed out                0
> N Number of successful tests:          47
> N + from this were verified:           6
>
> Orphaned tests:
> O Number of failed tests:              15
> O + from this fail compilation:        0
> O + from this timed out                0
> O Number of successful tests:          46
> O + from this were verified:           6
>
> when using "-fopenmp=libgomp -Xclang -fopenmp=libgomp
-L/sw/lib/gcc5/lib
> -lm -O3 -Wl,-no_compact_unwind". So we can't get much more broken
that the
> current behavior with libgomp.
>            Jack
>
> On Thu, Apr 30, 2015 at 9:49 AM, 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
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/17f24e66/attachment.html>