libiomp, not libgomp as default library linked with -fopenmp

[Finkel_Hal_J]

From: "Andrey Bokhanko" <andreybokhanko@gmail.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "cfe-dev" <cfe-dev@cs.uiuc.edu>, "LLVM Developers Mailing List" <llvmdev@cs.uiuc.edu>, "Douglas Gregor"
<dgregor@apple.com>, "C Bergström" <cbergstrom@pathscale.com>, "Michael Wong" <fraggamuffin@gmail.com>, "Alexey
Bataev" <a.bataev@gmx.com>, "chandlerc" <chandlerc@gmail.com>
Sent: Friday, May 1, 2015 3:09:09 AM
Subject: Re: libiomp, not libgomp as default library linked with -fopenmp

Hal,

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

Ah, that's good. -- Once the build-system integration is complete, we also need the regular buildbots to start doing this as well using the just-built trunk clang (just like we do for compiler-rt). I don't view that as a prerequisite to switching the linking default, but something we should do as soon as we can.

-Hal

[jwhowarth]

Chandler,

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

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 (
SPEC 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" (
Intel Broadwell: GCC 4.9 vs. LLVM Clang 3.5 Compiler Benchmarks - Phoronix)
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"?

Attached are preliminary benchmarking of John the Ripper 1.8.0 for clang
3.7svn with the two outstanding OPENMP patches applied and for gcc 5.1.0.
The attached john_the_ripper_clang-3.7.log and john_the_ripper_gcc-5.1.log
files contain the benchmarks at -O2 and -O3 for each compiler. As before,
the runs are from x86_64-apple-darwin14 using a early 2008 MacPro with dual
2.8GHz quad-core Xeon processors and 10 Gb of memory.

john_the_ripper_clang-3.7.log (2.36 KB)

john_the_ripper_gcc-5.1.log (2.2 KB)

[jwhowarth]

Chandler,

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

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 (
SPEC 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" (
Intel Broadwell: GCC 4.9 vs. LLVM Clang 3.5 Compiler Benchmarks - Phoronix)
and ImageMagick -- though latter is not included in most recent "clang vs
gcc" comparison.

Unfortunately, the current llvm 3.7svn and available OPENMP patches don't
allow for imageMagick-6.8.2 to compile. The build fails on the compiler
error...

magick/attribute.c:331:12: error: loop iteration variable in the associated
loop of 'omp parallel for' directive may not be threadprivate or thread
local, predetermined as
      private
      for (i=0; i < (ssize_t) image->colors; i++)
           ^
magick/attribute.c:325:9: note: loop iteration variable is predetermined as
linear
        i;
        ^
magick/attribute.c:978:12: error: loop iteration variable in the associated
loop of 'omp parallel for' directive may not be threadprivate or thread
local, predetermined as
      private
      for (i=0; i < (ssize_t) image->colors; i++)
           ^
magick/attribute.c:972:9: note: loop iteration variable is predetermined as
linear
        i;
        ^
2 errors generated.

I get the same error when I try to build the latest ImageMagick 6.9.1-2
sources with clang 3.7svn using -fopenmp=libiomp5 -Xclang -fopenmp=libiomp5.

[jwhowarth]

One other note. In testing the clang-omp compiler packaging that we did for the fink project, I aggregated as much openmp test code as I could find to validate its functionality. The current llvm 3.7svn with the two outstanding OPENMP patches applied builds and runs all of the example code listed on…

http://people.sc.fsu.edu/~jburkardt/c_src/ziggurat_openmp/ziggurat_openmp.html

for both c and c++ versions.

[jwhowarth]

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: ⚙ D9370 [OPENMP] Codegen for 'firstprivate' clause in 'task' directive.). 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

[Chandler_Carruth]

For me, I would prefer that the default switch for -fopenmp be towards the new name.

I freely admit this is a non-technical thing, I just think it helps send the correct message.

Also, as I said, I’m very sympathetic to the desire to support existing users of the existing name. I think we should at least either make it configurable or install symlinks under the old name… I actually think we should probably do both.

[Michael_Wong]

Don’t want to derail this train of discussion. But IBM and OpenMP fully support this move as we have actively worked on this with many other companies. We might be able to get a maintainer as well.

OpenMP CEO

[jwhowarth]

To be done simultaneously or can we stage them so that the name change is checked in after we stabilize the overall build and switch-over to openmp? I would hate to see things delayed over this when we have ages to switch the name before the 3.7 release. Also, might you not want to take that time for a more in-depth discussion about any changes related to so versioning? Do we expect to always just be able to use the same shared library name or will we have to explicitly version it for possible ABI changes later on. If we expect the existing ABI to never change but only see additions to the ABI as OpenMP 4.0 support is added, I guess that isn’t an issue. Perhaps such issues should be digested for awhile before jumping to a shared library name change.

[zygoloid]

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: ⚙ D9370 [OPENMP] Codegen for 'firstprivate' clause in 'task' directive.). 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?

[_C_Bergstrom]

I wish people who haven't been involved with the development wouldn't
get hung-up on the name. It's not user facing and the "branding"
doesn't really matter. (Do you really feel that strongly about this?)

Having the build time configure option makes this irrelevant and then
whoever is packaging it can name it whatevere they want.

(I hope I'm not coming across as rude)

[jwhowarth]

>>
>>>
>>> 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: ⚙ D9370 [OPENMP] Codegen for 'firstprivate' clause in 'task' directive.). 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?

I wish people who haven't been involved with the development wouldn't
get hung-up on the name. It's not user facing and the "branding"
doesn't really matter. (Do you really feel that strongly about this?)

Having the build time configure option makes this irrelevant and then
whoever is packaging it can name it whatevere they want.

IMHO, the openmp shared library falls in the same category as the c++ one
and should have some so versioning (whether it is libiomp5.1.dylib or
libiomp5.5.dylib) like libc++ does as /usr/lib/libc++.1.dylib on darwin.
That seems like a rational reason for renaming as opposed to just for
branding politics.

(I hope I'm not coming across as rude)

[zygoloid]

>>
>>>
>>> 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: ⚙ D9370 [OPENMP] Codegen for 'firstprivate' clause in 'task' directive.). 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?

I wish people who haven't been involved with the development wouldn't
get hung-up on the name.

No hang-ups here, just, as noted, bikeshedding.

It's not user facing and the "branding"
doesn't really matter. (Do you really feel that strongly about this?)

Chandler has a point that calling it libiomp makes it sound like an intel
library, which isn't appropriate for an LLVM subproject. Beyond that, I
don't really care, but it is something we should discuss and decide.

Having the build time configure option makes this irrelevant and then

whoever is packaging it can name it whatevere they want.

The LLVM project also acts as a packager for people downloading our release
tarballs. So we need to decide what we want to call this, as packagers.

[andreybokhanko]

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

[andreybokhanko]

+1

The longer one has to explicitly mention "libiomp5" in compiler
options, the better chances for this name to firmly stuck (in readmes,
howtows, tests / performance measurements, etc, etc)

Andrey

[andreybokhanko]

Jack,

Thank you for measuring this!

If I interpret results correctly (higher numbers = better
performance), clang + libiomp combo produces faster (sometimes
significantly faster) code in practically every case!

Andrey

[andreybokhanko]

Jack,

Could you, please, submit a bug report? -- including steps to
reproduce (where you got imageMagick sources, how exactly you compiled
them, etc)

Andrey

[jwhowarth]

Jack,

Could you, please, submit a bug report? -- including steps to
reproduce (where you got imageMagick sources, how exactly you compiled
them, etc)

Andrey,
       I opened...

https://llvm.org/bugs/show_bug.cgi?id=23387

This issue appears many times during the imagemagick build where the
register type being used in declaring loop iteration variables. The
preprocessed source attached to the bug report can be used to reproduce the
compiler error with the command...

# clang-3.7 -DHAVE_CONFIG_H -DMAGICKCORE_HDRI_ENABLE=1
-DMAGICKCORE_QUANTUM_DEPTH=16 -O3 -g -fopenmp=libiomp5 -Xclang
-fopenmp=libiomp5 -Wall -fexceptions -D_FORTIFY_SOURCE=0 -D_THREAD_SAFE
-DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -c attribute.i

where 'clang-3.7' is whatever you call your local clang 3.7svn compiler.
        Hopefully that should suffice to debug this (unless you are missing
some more entries in the openmp headers and the preprocessed source needs
to be regenerated).
                   Jack
ps This issue can be hacked around for now by removing usage the 'register'
type on the offending local iteration variable declarations which exposed a
second blocker in the imagemagick build...

https://llvm.org/bugs/show_bug.cgi?id=23392

due to a compiler ICE. The problem can be reproduced with the preprocessed
source attached to that report and the command...

clang-3.7 -DHAVE_CONFIG_H -DMAGICKCORE_HDRI_ENABLE=1
-DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp=libiomp5 -O2 -g -Xclang
-fopenmp=libiomp5 -L/sw/opt/llvm-3.7.0/lib -Wall -march=penryn -fexceptions
-D_FORTIFY_SOURCE=0 -D_THREAD_SAFE -pthread -DMAGICKCORE_HDRI_ENABLE=1
-DMAGICKCORE_QUANTUM_DEPTH=16 -c feature.i -fno-common -DPIC

The ICE smells like a similar issue with static support since the
compilation warnings include...

magick/feature.c:317:60: warning: extra tokens at the end of '#pragma omp
parallel for' are ignored [-Wextra-tokens] #pragma omp parallel for
schedule(static,4) shared(status)
magick_threads(edge_image,edge_image,edge_image->rows,1)
magick/feature.c:429:60: warning: extra tokens at the end of '#pragma omp
parallel for' are ignored [-Wextra-tokens] #pragma omp parallel for
schedule(static,4) shared(status)
magick_threads(edge_image,edge_image,edge_image->rows,1)

Andrey,

[jwhowarth]

+1

The longer one has to explicitly mention "libiomp5" in compiler
options, the better chances for this name to firmly stuck (in readmes,
howtows, tests / performance measurements, etc, etc)

Andrey

Andrey,
     The only thing I don't like about the libiomp5 name is the the 5. It
really should have been libiomp.5.dylib. Otherwise, when and if the ABI
changes after the initial release, you would have to switch the library
name to libiomp6 rather just bumping the so version to libiomp.6.dylib. I
worry that embedding the so version into the file name might complicate
doing configure/cmake checks for symbols in the shared library as the root
library name will keep changing over time.
                Jack

[jwhowarth]

Jack,

Thank you for measuring this!

If I interpret results correctly (higher numbers = better
performance), clang + libiomp combo produces faster (sometimes
significantly faster) code in practically every case!

According to John the Ripper benchmarks [Openwall Community Wiki], higher c/s rates
equals higher openmp performance. Note that they seem to value the result
from the DES crypt many/one salt over the other benchmark values and sort
their benchmark tables by that column.

[Joerg_Sonnenberger1]

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