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

Jack Howarth
2015-04-30T22:41:52Z

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?
>
> 2) I think we need to update the instructions for checking out LLVM and
> all the tools to include checking out the openmp project. I'm planning
to
> try it out in a bit.
>
> 3) It would be nice to get at least one boring benchmark into the
> test-suite that uses OpenMP just so there's more coverage that the
basic
> stuff all works. In particular, if we could get the benchmark that Phoronix
> and others keep pointing at, that'd be nice.
>
>
> Attached are two logs, taskbench_clang_3.7.log and taskbench_gcc_5.1.log,
with the output from the task_bench, task_firstpriv_bench and
taskwait_bench benchmarks run  on x86_64-apple-darwin14 using an early 2008
MacPro with dual 2.8 GHz quad-Xeon processors and 10 Gb of memory. The
clang 3.7svn compiler was current trunk with the remaining two OPENMP
patches on cfe-commits added to the build. The gcc compiler is release
5.1.0. In both cases, the -O3 -fopenmp flags were used. The
taskbench-1.0-20110715 release was used for the benchmark sources.

Speaking of which, have you checked the performance of some of the
basic
> benchmarks using OpenMP with the two runtimes? Or looked at Clang vs GCC
> there? I'd be interested to see the numbers.
>
>
>>
>> Yours,
>> Andrey Bokhanko
>> =============>> Software Engineer
>> Intel Compiler Team
>> Intel
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/b79f5307/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: taskbench_clang_3.7.log
Type: application/octet-stream
Size: 10216 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/b79f5307/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: taskbench_gcc_5.1.log
Type: application/octet-stream
Size: 9909 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150430/b79f5307/attachment-0001.obj>