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

Hal Finkel hfinkel at anl.gov
Tue May 5 09:39:05 PDT 2015


----- Original Message -----

> From: "Richard Smith" <richard at metafoo.co.uk>
> To: "Chandler Carruth" <chandlerc at google.com>
> Cc: "Andrey Bokhanko" <andreybokhanko at gmail.com>, "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: Friday, May 1, 2015 1:31:06 PM
> Subject: Re: [LLVMdev] libiomp, not libgomp as default library linked
> with -fopenmp

> 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 agree. However, for dynamic executables we need a dynamic OpenMP runtime library (there can be only one in the process because it has to keep process-wide state). The ABI is stable, and has a fairly-extensive history (on x86, specifically). cc'ing Jim so he can also comment directly. 

-Hal 

> - 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.

> 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

> --
Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150505/1b90c2b3/attachment.html>


More information about the llvm-dev mailing list