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

[Chandler Carruth]

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>