[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