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

C Bergström
Fri, 01 May 2015 18:36:12 -0000

On Sat, May 2, 2015 at 1:31 AM, Richard Smith <richard at metafoo.co.uk>
wrote:
> On Thu, Apr 30, 2015 at 2: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.
>
>
> 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.

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