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

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 Fri, May 1, 2015 at 10:46 AM Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:
> 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.
>
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*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/e83be435/attachment.html>

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

Sent from my iPhone
> On May 1, 2015, at 1:46 PM, Jack Howarth <howarth.mailing.lists at
gmail.com> wrote:
> 
> 
> 
>> 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/a0a668fa/attachment.html>

On Fri, May 1, 2015 at 1:57 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> On Fri, May 1, 2015 at 10:46 AM Jack Howarth <
> howarth.mailing.lists at gmail.com> wrote:
>
>> 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.
>>
>
> 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*.
>

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