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

C Bergström cbergstrom at pathscale.com
Thu Apr 30 07:25:25 PDT 2015


On Thu, Apr 30, 2015 at 9:06 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> From: "Andrey Bokhanko" <andreybokhanko at gmail.com>
>> To: "cfe-dev" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Douglas Gregor"
>> <dgregor at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "C Bergström" <cbergstrom at pathscale.com>, "Michael Wong"
>> <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev at gmx.com>
>> Sent: Thursday, April 30, 2015 8:49:30 AM
>> Subject: libiomp, not libgomp as default library linked with -fopenmp
>>
>>
>> All,
>>
>>
>> I'd like to resurrect the discussion on replacing libgomp with
>> libiomp as the default OpenMP runtime library linked with -fopenmp.
>>
>>
>> For reference, the previous discussion is accessible there:
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461
>>
>>
>> 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.
>
> To be clear, this is now LLVM's OpenMP runtime (not just Intel's), and has been ported to several platforms in addition to x86 (PowerPC, ARM).

It doesn't really feel that way. I proposed a cmake patch and the only
person to review or comment was Intel. (This is coming from the person
who ported it to ARM)

To stay more agnostic I'd love to see a non-Intel owner. While Hal may
not be the most active contributor - his reviews are invaluable and
less biased. I don't know if Hal has the time or interest, but I'd
nominate him for "owner". I see Tom wants to assign more owners, but
I'd like to avoid this being an "Intel runtime owned and controlled by
Intel"




More information about the llvm-dev mailing list