[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp
Andrey Bokhanko
andreybokhanko at gmail.com
Fri May 1 01:13:20 PDT 2015
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>
More information about the llvm-dev
mailing list