<div dir="ltr"><div>Chandler,<br><br></div>Thanks for the reply -- I always included you in libiomp supporters camp; it is good to see I wasn't mistaken! ;-)<br><br><div class="gmail_extra"><div class="gmail_quote">On Fri, May 1, 2015 at 12:51 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""></span>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. =]</div></div></blockquote><div><br></div><div>No, sorry. libgomp doesn't support Intel API and clang generates Intel API calls only -- as simple as that. Someday someone may implement generation of GNU API calls as well, but this is a separate big task that, IMHO, doesn't serve any real purpose -- and potentially introduces nasty GPL-related legal issues.<br><br></div><div>There is an option to choose what library clang links (-fopenmp={libiomp|libgomp}), though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">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.<div><br></div><div>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:</div><div>- 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.</div></div></div></blockquote><div><br></div><div>This really belongs to a separate thread (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/085037.html</a>); see my answer there in a couple of minutes.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>- Clearly updating the readme and such would be appropriate.</div><div>- 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.</div><div>- Any other changes?</div></div></div></blockquote><div><br></div><div>Adding openmp-dev list (in retrospect, should have been done at the very start...), Jim Cownie and Andrey Churbanov.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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.</div></div></div></blockquote><div><br></div><div>Cool! Thank you!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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.</div></div></div></blockquote><div></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>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.</div><div></div></div></div></blockquote><div><br><div>This is very tricky for me -- I'm employed by a CPU vendor (Intel),
 and we have very strict rules and long processes for publishing benchmark
 results. I simply can't run a benchmark and say: "hey! clang has this number and gcc has that number".<br></div><div><br></div><div>The
 only thing I can share is that we do tested SPEC OMP2012 
(<a href="https://www.spec.org/omp2012/">https://www.spec.org/omp2012/</a>), which is the industry standard for OMP 
benchmarks, on a non-server class Darwin machine, and the results are quite good and comparable with other compilers.<br><br></div><div>Speaking on Phoronix,
 two benchmarks where clang always lose due to lack of OpenMP are "John the 
Ripper" 
(<a href="http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3">http://www.phoronix.com/scan.php?page=article&item=clang-gcc-broadwell&num=3</a>) and ImageMagick -- though latter is not included in most recent "clang vs gcc" comparison.<br><br></div><div>Is there a generous soul (not employed by a CPU vendor :-)) willing to run "John the Ripper" with "clang -fopenmp=libiomp5 -Xclang -fopenmp=libiomp5 -lm -O3" and compare results with "clang -O3"?<br></div><br></div><div>Also, Jack Howarth did testing with some other benchmarks, and it is nice to see that clang + libiomp compare quite well (to say it mildly ;-)) with gcc + libgomp!<br></div><div> </div>Andrey<br><br></div></div></div>