<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><hr id="zwchr"><br><blockquote id="DWT2630"> From: "Richard Smith" <richard@metafoo.co.uk><br> To: "Chandler Carruth" <chandlerc@google.com><br> Cc: "Andrey Bokhanko" <andreybokhanko@gmail.com>, "cfe-dev" <cfe-dev@cs.uiuc.edu>, "LLVM Developers Mailing List"<br> <llvmdev@cs.uiuc.edu>, "Douglas Gregor" <dgregor@apple.com>, "Hal Finkel" <hfinkel@anl.gov>, "C Bergström"<br> <cbergstrom@pathscale.com>, "Michael Wong" <fraggamuffin@gmail.com>, "Alexey Bataev" <a.bataev@gmx.com><br> Sent: Friday, May 1, 2015 1:31:06 PM<br> Subject: Re: [LLVMdev] libiomp, not libgomp as default library linked with -fopenmp<br> <br> <br> <br> <br> On Thu, Apr 30, 2015 at 2:51 PM, Chandler Carruth <<br> chandlerc@google.com > wrote:<br> <br> <br> <br> <br> On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <<br> andreybokhanko@gmail.com > wrote:<br> <br> <br> <br> All,<br> <br> <br> I'd like to resurrect the discussion on replacing libgomp with<br> libiomp as the default OpenMP runtime library linked with -fopenmp.<br> <br> <br> Just for the record, I'm really excited to see this. =]<br> <br> <br> <br> <br> We are very close to getting *full* OpenMP 3.1 specification<br> supported in clang (only one (!) clause is not implemented yet, and<br> the patch is already sent for review today:<br> http://reviews.llvm.org/D9370 ). This implementation generates Intel<br> API library calls; thus, it can't be used with libgomp and it is<br> simply logical to link a compatible runtime (libiomp) instead.<br> <br> <br> <br> Is there no way to support libgomp here as well? I don't say this to<br> hold up changing the defaults in any way, just curious. =]<br> <br> <br> Also, for the record, I'm really excited to see the progress here as<br> well.<br> <br> <br> <br> <br> Chandler?<br> <br> <br> <br> Hi! ;]<br> <br> <br> I totally agree, I think things are way better now. I generally<br> support the direction. I think there are a few things I'd suggest we<br> do as part of the process, but I think these are really small and<br> just about "how" we switch.<br> <br> <br> 1) I completely agree with the comments some others have made about<br> us needing to make it clear that this isn't some Intel-only thing,<br> its the LLVM OpenMP runtime. Some suggestions that I think would<br> make sense to help here:<br> - I agree with finding some non-Intel folks to add as explicit code<br> owners. I don't know who has been sufficiently involved, but if Hal<br> makes sense, awesome.<br> - Clearly updating the readme and such would be appropriate.<br> - I suspect we should change the name of the installed library.<br> 'libiomp' is pretty clearly the Intel library. We could continue in<br> the grand tradition of LLVM naming conventions and use 'libllomp'?<br> Of course, we should install symlinks under the name 'libiomp' if<br> needed for existing users to not be broken.<br> <br> <br> Just some bikeshed-painting: if we're expecting each compiler that<br> uses the library to distribute a separate copy as part of that<br> compiler's runtime, then I think the best name for clang to use for<br> the library would probably be libclang_rt.omp-<arch> or<br> libclang_rt.openmp-<arch> (as we do for all our other runtime<br> libraries). If we expect this to be installed somewhere central on<br> the system and shared by different compilers and different versions<br> of the same compiler, then libllomp or similar seems reasonable to<br> me. What's the intended distribution model here? How stable is the<br> ABI?<br> <br></blockquote><br>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.<br><br> -Hal<br><br><blockquote> <br> <br> <br> <br> <br> <br> - Any other changes?<br> <br> <br> 2) I think we need to update the instructions for checking out LLVM<br> and all the tools to include checking out the openmp project. I'm<br> planning to try it out in a bit.<br> <br> <br> 3) It would be nice to get at least one boring benchmark into the<br> test-suite that uses OpenMP just so there's more coverage that the<br> basic stuff all works. In particular, if we could get the benchmark<br> that Phoronix and others keep pointing at, that'd be nice.<br> <br> <br> <br> <br> Speaking of which, have you checked the performance of some of the<br> basic benchmarks using OpenMP with the two runtimes? Or looked at<br> Clang vs GCC there? I'd be interested to see the numbers.<br> <br> <br> <br> <br> <br> <br> <br> Yours,<br> Andrey Bokhanko<br> ==============<br> Software Engineer<br> Intel Compiler Team<br> Intel<br> <br> _______________________________________________<br> LLVM Developers mailing list<br> LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br> <br> _______________________________________________<br> LLVM Developers mailing list<br> LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br> <br> <br> <br><br>-- </blockquote><br>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<br></div></body></html>