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

[Andrey Bokhanko]

+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


On Fri, May 1, 2015 at 9:16 PM, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
>
>
> 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.
>