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

[Andrey Bokhanko]

Jack,

I really have no strong opinion on library name -- and frankly prefer
to leave the decision to library pros.

My point is that as soon as LLVM version of OMP runtime lib (libiomp5,
libiomp, libllvmomp, ... whatever you name it) will become the default
for "-fopenmp", the users won't have to mention the name explicitly
and thus, won't be disrupted with name changes at all.

Andrey


On Sun, May 3, 2015 at 1:20 AM, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
>
>
> On Sat, May 2, 2015 at 4:22 PM, Andrey Bokhanko <andreybokhanko at gmail.com>
> wrote:
>>
>> +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
>
>>
>> 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.
>> >
>
>