llvm dev - May 2015 - [LLVMdev] [cfe-dev] libiomp, not libgomp as default library linked with -fopenmp

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/llvm-dev/attachments/20150430/f13af52a/attachment.html>

----- Original Message -----
> From: "Andrey Bokhanko" <andreybokhanko at gmail.com>
> To: "cfe-dev" <cfe-dev at cs.uiuc.edu>, "LLVM
Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Douglas
Gregor"
> <dgregor at apple.com>, "Hal Finkel" <hfinkel at
anl.gov>, "C Bergström" <cbergstrom at pathscale.com>,
"Michael Wong"
> <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev
at gmx.com>
> Sent: Thursday, April 30, 2015 8:49:30 AM
> Subject: libiomp, not libgomp as default library linked with -fopenmp
> 
> 
> 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.
To be clear, this is now LLVM's OpenMP runtime (not just Intel's), and
has been ported to several platforms in addition to x86 (PowerPC, ARM).
> 
> 
> 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?
> 
I support this. Linking to libgomp will still be available by specifying
-fopenmp=libgomp for those who need it. Our runtime supports a
libgomp-compatible interface, so that's hopefully not necessary even for
those with GCC-compiled OpenMP object files and libraries.

We need to get the build system integration committed and the buildbots updated
to compile it, and the test suite setup (the build system integration and
test-suite setup have patches under review on the openmp list, so I suspect this
will happen soon). Practically, since we don't have OpenMP in the test suite
(yet), none of these are really inflexible prerequisites. In my opinion, as soon
as the build system integration is done (so that people have an easy way to use
LLVM's runtime), we should flip the defaults -- the other things will follow
shortly.

 -Hal
> 
> 
> 
> Anyone who disagrees?
> 
> 
> 
> 
> Chandler?
> 
> 
> Yours,
> Andrey Bokhanko
> =============> Software Engineer
> Intel Compiler Team
> Intel
> 
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

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/20150430/9c27d7da/attachment.html>

On Thu, Apr 30, 2015 at 9:06 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
> ----- Original Message -----
>> From: "Andrey Bokhanko" <andreybokhanko at gmail.com>
>> To: "cfe-dev" <cfe-dev at cs.uiuc.edu>, "LLVM
Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Douglas
Gregor"
>> <dgregor at apple.com>, "Hal Finkel" <hfinkel at
anl.gov>, "C Bergström" <cbergstrom at pathscale.com>,
"Michael Wong"
>> <fraggamuffin at gmail.com>, "Alexey Bataev"
<a.bataev at gmx.com>
>> Sent: Thursday, April 30, 2015 8:49:30 AM
>> Subject: libiomp, not libgomp as default library linked with -fopenmp
>>
>>
>> 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.
>
> To be clear, this is now LLVM's OpenMP runtime (not just Intel's),
and has been ported to several platforms in addition to x86 (PowerPC, ARM).
It doesn't really feel that way. I proposed a cmake patch and the only
person to review or comment was Intel. (This is coming from the person
who ported it to ARM)

To stay more agnostic I'd love to see a non-Intel owner. While Hal may
not be the most active contributor - his reviews are invaluable and
less biased. I don't know if Hal has the time or interest, but I'd
nominate him for "owner". I see Tom wants to assign more owners, but
I'd like to avoid this being an "Intel runtime owned and controlled by
Intel"

I definitely support Andrey’s proposal to move the default to libiomp.  Outside
of the known ports for x86, ARM and PowerPC, I’m aware of at least one other
port in progress.  More will likely follow.

Per Hal’s notes, given the forthcoming commits of the CMake build system,
flipping the default to libiomp may help spur/accelerate the progress of porting
the runtime to new platforms (especially those that are already supported as
LLVM backends).

--John D. Leidel


On Apr 30, 2015, at 9:06 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> From: "Andrey Bokhanko" <andreybokhanko at gmail.com>
>> To: "cfe-dev" <cfe-dev at cs.uiuc.edu>, "LLVM
Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Douglas
Gregor"
>> <dgregor at apple.com>, "Hal Finkel" <hfinkel at
anl.gov>, "C Bergström" <cbergstrom at pathscale.com>,
"Michael Wong"
>> <fraggamuffin at gmail.com>, "Alexey Bataev"
<a.bataev at gmx.com>
>> Sent: Thursday, April 30, 2015 8:49:30 AM
>> Subject: libiomp, not libgomp as default library linked with -fopenmp
>> 
>> 
>> 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.
> 
> To be clear, this is now LLVM's OpenMP runtime (not just Intel's),
and has been ported to several platforms in addition to x86 (PowerPC, ARM).
> 
>> 
>> 
>> 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?
>> 
> 
> I support this. Linking to libgomp will still be available by specifying
-fopenmp=libgomp for those who need it. Our runtime supports a
libgomp-compatible interface, so that's hopefully not necessary even for
those with GCC-compiled OpenMP object files and libraries.
> 
> We need to get the build system integration committed and the buildbots
updated to compile it, and the test suite setup (the build system integration
and test-suite setup have patches under review on the openmp list, so I suspect
this will happen soon). Practically, since we don't have OpenMP in the test
suite (yet), none of these are really inflexible prerequisites. In my opinion,
as soon as the build system integration is done (so that people have an easy way
to use LLVM's runtime), we should flip the defaults -- the other things will
follow shortly.
> 
> -Hal
> 
>> 
>> 
>> 
>> Anyone who disagrees?
>> 
>> 
>> 
>> 
>> Chandler?
>> 
>> 
>> Yours,
>> Andrey Bokhanko
>> =============>> Software Engineer
>> Intel Compiler Team
>> Intel
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Thu, Apr 30, 2015 at 10:23 AM, 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
>
>
For additional context, the OpenMP3.1_Validation results for libgomp using
the FSF gcc 5.1.0  compiler on x86_64-apple-darwin14 are...

Summary:
S Number of tested Open MP constructs: 62
S Number of used tests:                123
S Number of failed tests:              7
S Number of successful tests:          116
S + from this were verified:           95

Normal tests:
N Number of failed tests:              3
N + from this fail compilation:        0
N + from this timed out                0
N Number of successful tests:          59
N + from this were verified:           48

Orphaned tests:
O Number of failed tests:              4
O + from this fail compilation:        0
O + from this timed out                0
O Number of successful tests:          57
O + from this were verified:           47

So the current results for libiomp5 are very close to matching those for
the FSF gcc compiler with libgomp in terms of the number of passed tests
while libiomp5 already exceeds libgomp for the number of verified tests.

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/20150430/6043d4ff/attachment.html>

On 30 April 2015 at 10:06, Hal Finkel <hfinkel at anl.gov>
wrote:
>>
>> 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.
>
> To be clear, this is now LLVM's OpenMP runtime (not just Intel's),
and has been ported to several platforms in addition to x86 (PowerPC, ARM).
It looks like openmp/runtime/README.txt could use an update to clarify
this status. The title is "README for the Intel(R) OpenMP* Runtime
Library" and there's a of supported Intel architectures -- this gives
a somewhat different impression than what's described in this thread.

That said, I would also be happy to see the default switched to libiomp.

On Thu, Apr 30, 2015 at 6:52 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.
>
Just for the record, I'm really excited to see this. =]

> 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.
>
Is there no way to support libgomp here as well? I don't say this to hold
up changing the defaults in any way, just curious. =]

Also, for the record, I'm really excited to see the progress here as well.

> Chandler?
>
Hi! ;]

I totally agree, I think things are way better now. I generally support the
direction. I think there are a few things I'd suggest we do as part of the
process, but I think these are really small and just about "how" we
switch.

1) I completely agree with the comments some others have made about us
needing to make it clear that this isn't some Intel-only thing, its the
LLVM OpenMP runtime. Some suggestions that I think would make sense to help
here:
- I agree with finding some non-Intel folks to add as explicit code owners.
I don't know who has been sufficiently involved, but if Hal makes sense,
awesome.
- Clearly updating the readme and such would be appropriate.
- I suspect we should change the name of the installed library.
'libiomp'
is pretty clearly the Intel library. We could continue in the grand
tradition of LLVM naming conventions and use 'libllomp'? Of course, we
should install symlinks under the name 'libiomp' if needed for existing
users to not be broken.
- Any other changes?

2) I think we need to update the instructions for checking out LLVM and all
the tools to include checking out the openmp project. I'm planning to try
it out in a bit.

3) It would be nice to get at least one boring benchmark into the
test-suite that uses OpenMP just so there's more coverage that the basic
stuff all works. In particular, if we could get the benchmark that Phoronix
and others keep pointing at, that'd be nice.


Speaking of which, have you checked the performance of some of the basic
benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC
there? I'd be interested to see the numbers.

>
> 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/20150430/e6bb5285/attachment.html>

I'm trimming everything - sorry too hard to manage the thread in my
current email client
--
1) I'd rather see a configure time option to change the name rather
than just switching it. It's not user facing and who really cares what
the name is. (I don't) It's one more change for others who have
established naming (Intel) to have to carry a patch. (I'd like to play
nice here.. UH, PathScale, foobar may also want to use a different
name.. etc)

2) Benchmarks - There's SPEC OMP2012, but I'm not sure if a gcc vs
llvm comparison is really going to stress the runtime sufficiently
enough to play the blame game. The retired OMP benchmark may use a
limited enough subset of features to work with llvm+gomp||iomp.. (That
way you could do a 1:1 comparison) - If that does work I'm not yet
confident it would expose any real performance issues in the runtime.
(You'd need to test it on a system with *A LOT* of cores)

There are lowering differences between the internal API as well..

Ancedotal evidence - Intel's runtime (essentially the same code as
"llvm omp") is used by Intel for OMP SPEC submissions as compared to
nobody publishing record setting performance with gomp...

On Thu, Apr 30, 2015 at 5:51 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
> On Thu, Apr 30, 2015 at 6:52 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.
>>
>
> Just for the record, I'm really excited to see this. =]
>
>
>> 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.
>>
>
> Is there no way to support libgomp here as well? I don't say this to
hold
> up changing the defaults in any way, just curious. =]
>
> Also, for the record, I'm really excited to see the progress here as
well.
>
>
>> Chandler?
>>
>
> Hi! ;]
>
> I totally agree, I think things are way better now. I generally support
> the direction. I think there are a few things I'd suggest we do as part
of
> the process, but I think these are really small and just about
"how" we
> switch.
>
> 1) I completely agree with the comments some others have made about us
> needing to make it clear that this isn't some Intel-only thing, its the
> LLVM OpenMP runtime. Some suggestions that I think would make sense to help
> here:
> - I agree with finding some non-Intel folks to add as explicit code
> owners. I don't know who has been sufficiently involved, but if Hal
makes
> sense, awesome.
> - Clearly updating the readme and such would be appropriate.
> - I suspect we should change the name of the installed library.
'libiomp'
> is pretty clearly the Intel library. We could continue in the grand
> tradition of LLVM naming conventions and use 'libllomp'? Of course,
we
> should install symlinks under the name 'libiomp' if needed for
existing
> users to not be broken.
> - Any other changes?
>
> 2) I think we need to update the instructions for checking out LLVM and
> all the tools to include checking out the openmp project. I'm planning
to
> try it out in a bit.
>
> 3) It would be nice to get at least one boring benchmark into the
> test-suite that uses OpenMP just so there's more coverage that the
basic
> stuff all works. In particular, if we could get the benchmark that Phoronix
> and others keep pointing at, that'd be nice.
>
>
> Attached are two logs, taskbench_clang_3.7.log and taskbench_gcc_5.1.log,
with the output from the task_bench, task_firstpriv_bench and
taskwait_bench benchmarks run  on x86_64-apple-darwin14 using an early 2008
MacPro with dual 2.8 GHz quad-Xeon processors and 10 Gb of memory. The
clang 3.7svn compiler was current trunk with the remaining two OPENMP
patches on cfe-commits added to the build. The gcc compiler is release
5.1.0. In both cases, the -O3 -fopenmp flags were used. The
taskbench-1.0-20110715 release was used for the benchmark sources.

Speaking of which, have you checked the performance of some of the
basic
> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC
> there? I'd be interested to see the numbers.
>
>
>>
>> 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
>>
>
> _______________________________________________
> 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/20150430/b79f5307/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: taskbench_clang_3.7.log
Type: application/octet-stream
Size: 10216 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/b79f5307/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: taskbench_gcc_5.1.log
Type: application/octet-stream
Size: 9909 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/b79f5307/attachment-0001.obj>

On Thu, Apr 30, 2015 at 5:51 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
> On Thu, Apr 30, 2015 at 6:52 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.
>>
>
> Just for the record, I'm really excited to see this. =]
>
>
>> 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.
>>
>
> Is there no way to support libgomp here as well? I don't say this to
hold
> up changing the defaults in any way, just curious. =]
>
> Also, for the record, I'm really excited to see the progress here as
well.
>
>
>> Chandler?
>>
>
> Hi! ;]
>
> I totally agree, I think things are way better now. I generally support
> the direction. I think there are a few things I'd suggest we do as part
of
> the process, but I think these are really small and just about
"how" we
> switch.
>
> 1) I completely agree with the comments some others have made about us
> needing to make it clear that this isn't some Intel-only thing, its the
> LLVM OpenMP runtime. Some suggestions that I think would make sense to help
> here:
> - I agree with finding some non-Intel folks to add as explicit code
> owners. I don't know who has been sufficiently involved, but if Hal
makes
> sense, awesome.
> - Clearly updating the readme and such would be appropriate.
> - I suspect we should change the name of the installed library.
'libiomp'
> is pretty clearly the Intel library. We could continue in the grand
> tradition of LLVM naming conventions and use 'libllomp'? Of course,
we
> should install symlinks under the name 'libiomp' if needed for
existing
> users to not be broken.
> - Any other changes?
>
> 2) I think we need to update the instructions for checking out LLVM and
> all the tools to include checking out the openmp project. I'm planning
to
> try it out in a bit.
>
> 3) It would be nice to get at least one boring benchmark into the
> test-suite that uses OpenMP just so there's more coverage that the
basic
> stuff all works. In particular, if we could get the benchmark that Phoronix
> and others keep pointing at, that'd be nice.
>
>
> Speaking of which, have you checked the performance of some of the basic
> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC
> there? I'd be interested to see the numbers.
>
Another set of benchmark numbers are attached in
openmpbench_C_v3_clang-3.7.log and openmpbench_C_v3_gcc_5.1.log using the
schedbench, syncbench and taskbench compiled with the default -O1
optimization using the clang 3.7svn trunk with the two remaining OPENMP
patches from cfe-commits and the gcc 5.1.0 release compiler. The
OMP_NUM_THREADS=4 is set before each set of runs which were performed on
x86_64-apple-darwin14 using a early 2008 MacPro with dual 2.8 GHz quad-core
Xeon processors and 10 Gb of memory. The benchmark is detailed at
https://www.epcc.ed.ac.uk/research/computing/performance-characterisation-and-benchmarking/epcc-openmp-micro-benchmark-suite
.
>
>
>
>>
>> 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
>>
>
> _______________________________________________
> 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/20150430/d6d0ce27/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openmpbench_C_v3_clang-3.7.log
Type: application/octet-stream
Size: 18318 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/d6d0ce27/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openmpbench_C_v3_gcc_5.1.log
Type: application/octet-stream
Size: 18498 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/d6d0ce27/attachment-0001.obj>

Hal,

On Thu, Apr 30, 2015 at 5:06 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> We need to get the build system integration committed and the buildbots
> updated to compile it
>
If you are speaking on libiomp buidbots, they are already established:
http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian
http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian

Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/c17880e5/attachment.html>

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>

Chandler,

Thanks for the reply -- I always included you in libiomp supporters camp;
it is good to see I wasn't mistaken! ;-)

On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <chandlerc at
google.com>
wrote:
> Is there no way to support libgomp here as well? I don't say this to
hold
> up changing the defaults in any way, just curious. =]
>
No, sorry. libgomp doesn't support Intel API and clang generates Intel API
calls only -- as simple as that. Someday someone may implement generation
of GNU API calls as well, but this is a separate big task that, IMHO,
doesn't serve any real purpose -- and potentially introduces nasty
GPL-related legal issues.

There is an option to choose what library clang links
(-fopenmp={libiomp|libgomp}), though.

> I totally agree, I think things are way better now. I generally support
> the direction. I think there are a few things I'd suggest we do as part
of
> the process, but I think these are really small and just about
"how" we
> switch.
>
> 1) I completely agree with the comments some others have made about us
> needing to make it clear that this isn't some Intel-only thing, its the
> LLVM OpenMP runtime. Some suggestions that I think would make sense to help
> here:
> - I agree with finding some non-Intel folks to add as explicit code
> owners. I don't know who has been sufficiently involved, but if Hal
makes
> sense, awesome.
>
This really belongs to a separate thread (
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html); see my
answer there in a couple of minutes.

> - Clearly updating the readme and such would be appropriate.
> - I suspect we should change the name of the installed library.
'libiomp'
> is pretty clearly the Intel library. We could continue in the grand
> tradition of LLVM naming conventions and use 'libllomp'? Of course,
we
> should install symlinks under the name 'libiomp' if needed for
existing
> users to not be broken.
> - Any other changes?
>
Adding openmp-dev list (in retrospect, should have been done at the very
start...), Jim Cownie and Andrey Churbanov.

> 2) I think we need to update the instructions for checking out LLVM and
> all the tools to include checking out the openmp project. I'm planning
to
> try it out in a bit.
>
Cool! Thank you!

> 3) It would be nice to get at least one boring benchmark into the
> test-suite that uses OpenMP just so there's more coverage that the
basic
> stuff all works. In particular, if we could get the benchmark that Phoronix
> and others keep pointing at, that'd be nice.
>
Speaking of which, have you checked the performance of some of the
basic
> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC
> there? I'd be interested to see the numbers.
>
This is very tricky for me -- I'm employed by a CPU vendor (Intel), and we
have very strict rules and long processes for publishing benchmark results.
I simply can't run a benchmark and say: "hey! clang has this number and
gcc
has that number".

The only thing I can share is that we do tested SPEC OMP2012 (
https://www.spec.org/omp2012/), which is the industry standard for OMP
benchmarks, on a non-server class Darwin machine, and the results are quite
good and comparable with other compilers.

Speaking on Phoronix, two benchmarks where clang always lose due to lack of
OpenMP are "John the Ripper" (
http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3)
and ImageMagick -- though latter is not included in most recent "clang vs
gcc" comparison.

Is there a generous soul (not employed by a CPU vendor :-)) willing to run
"John the Ripper" with "clang -fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5
-lm -O3" and compare results with "clang -O3"?

Also, Jack Howarth did testing with some other benchmarks, and it is nice
to see that clang + libiomp compare quite well (to say it mildly ;-)) with
gcc + libgomp!

Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/30c3c3cc/attachment.html>

On Thu, Apr 30, 2015 at 5:51 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
> On Thu, Apr 30, 2015 at 6:52 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.
>>
>
> Just for the record, I'm really excited to see this. =]
>
>
>> 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.
>>
>
> Is there no way to support libgomp here as well? I don't say this to
hold
> up changing the defaults in any way, just curious. =]
>
> Also, for the record, I'm really excited to see the progress here as
well.
>
>
>> Chandler?
>>
>
> Hi! ;]
>
> I totally agree, I think things are way better now. I generally support
> the direction. I think there are a few things I'd suggest we do as part
of
> the process, but I think these are really small and just about
"how" we
> switch.
>
> 1) I completely agree with the comments some others have made about us
> needing to make it clear that this isn't some Intel-only thing, its the
> LLVM OpenMP runtime. Some suggestions that I think would make sense to help
> here:
> - I agree with finding some non-Intel folks to add as explicit code
> owners. I don't know who has been sufficiently involved, but if Hal
makes
> sense, awesome.
> - Clearly updating the readme and such would be appropriate.
> - I suspect we should change the name of the installed library.
'libiomp'
> is pretty clearly the Intel library. We could continue in the grand
> tradition of LLVM naming conventions and use 'libllomp'? Of course,
we
> should install symlinks under the name 'libiomp' if needed for
existing
> users to not be broken.
> - Any other changes?
>
>
Is this naming issue so serious that it will be blocker for the current
patches to enabled the openmp build from within llvm/projects? Can't we
just proceed with the current library name until the top-level openmp build
infrastructure added and the switch of the default for -fopenmp to libiomp5
is made. It seems more sensible to stabilize the openmp support first and
then revisit the naming issue in a couple of weeks.

2) I think we need to update the instructions for checking out LLVM and
all
> the tools to include checking out the openmp project. I'm planning to
try
> it out in a bit.
>
> 3) It would be nice to get at least one boring benchmark into the
> test-suite that uses OpenMP just so there's more coverage that the
basic
> stuff all works. In particular, if we could get the benchmark that Phoronix
> and others keep pointing at, that'd be nice.
>
>
> Speaking of which, have you checked the performance of some of the basic
> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC
> there? I'd be interested to see the numbers.
>
>
>>
>> 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
>>
>
> _______________________________________________
> 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/1838e7f9/attachment.html>

On Thu, Apr 30, 2015 at 2:51 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
> On Thu, Apr 30, 2015 at 6:52 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.
>>
>
> Just for the record, I'm really excited to see this. =]
>
>
>> 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.
>>
>
> Is there no way to support libgomp here as well? I don't say this to
hold
> up changing the defaults in any way, just curious. =]
>
> Also, for the record, I'm really excited to see the progress here as
well.
>
>
>> Chandler?
>>
>
> Hi! ;]
>
> I totally agree, I think things are way better now. I generally support
> the direction. I think there are a few things I'd suggest we do as part
of
> the process, but I think these are really small and just about
"how" we
> switch.
>
> 1) I completely agree with the comments some others have made about us
> needing to make it clear that this isn't some Intel-only thing, its the
> LLVM OpenMP runtime. Some suggestions that I think would make sense to help
> here:
> - I agree with finding some non-Intel folks to add as explicit code
> owners. I don't know who has been sufficiently involved, but if Hal
makes
> sense, awesome.
> - Clearly updating the readme and such would be appropriate.
> - I suspect we should change the name of the installed library.
'libiomp'
> is pretty clearly the Intel library. We could continue in the grand
> tradition of LLVM naming conventions and use 'libllomp'? Of course,
we
> should install symlinks under the name 'libiomp' if needed for
existing
> users to not be broken.
>
Just some bikeshed-painting: if we're expecting each compiler that uses the
library to distribute a separate copy as part of that compiler's runtime,
then I think the best name for clang to use for the library would probably
be libclang_rt.omp-<arch> or libclang_rt.openmp-<arch> (as we do for
all
our other runtime libraries). If we expect this to be installed somewhere
central on the system and shared by different compilers and different
versions of the same compiler, then libllomp or similar seems reasonable to
me. What's the intended distribution model here? How stable is the ABI?

- Any other changes?
>
> 2) I think we need to update the instructions for checking out LLVM and
> all the tools to include checking out the openmp project. I'm planning
to
> try it out in a bit.
>
> 3) It would be nice to get at least one boring benchmark into the
> test-suite that uses OpenMP just so there's more coverage that the
basic
> stuff all works. In particular, if we could get the benchmark that Phoronix
> and others keep pointing at, that'd be nice.
>
>
> Speaking of which, have you checked the performance of some of the basic
> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC
> there? I'd be interested to see the numbers.
>
>
>>
>> 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
>>
>
> _______________________________________________
> 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/ec22f5b1/attachment.html>

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
>

On Sat, May 02, 2015 at 11:18:35PM +0300, Andrey Bokhanko
wrote:
> 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?
Switch the library name together with the default value for clang. That
seems like to the way forward. It doesn't break existing users, since
they would still be using -fopenmp=libiomp5 and it doesn't introduce a
surprise for new users after the lib name change.

Joerg