<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 1:57 PM, 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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="">On Fri, May 1, 2015 at 10:46 AM Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 30, 2015 at 5:51 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span>On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">All,<div><br></div><div>I'd like to resurrect the discussion on replacing libgomp with libiomp as the default OpenMP runtime library linked with -fopenmp.</div></div></blockquote><div><br></div></span><div>Just for the record, I'm really excited to see this. =]</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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: <a href="http://reviews.llvm.org/D9370" target="_blank">http://reviews.llvm.org/D9370</a>). 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.<br></div></div></blockquote><div><br></div></span><div>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><br></div><div>Also, for the record, I'm really excited to see the progress here as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Chandler?<br></div></div></blockquote><div><br></div><div>Hi! ;]</div><div><br></div><div>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><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>- 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><br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Is this naming issue so serious that it will be blocker for the current patches to enabled the openmp build from within llvm/projects? Can't we just proceed with the current library name until the top-level openmp build infrastructure added and the switch of the default for -fopenmp to libiomp5 is made. It seems more sensible to stabilize the openmp support first and then revisit the naming issue in a couple of weeks.</div></div></div></div></blockquote><div><br></div></span><div>For me, I would prefer that the default switch for -fopenmp be towards the new name.</div><div><br></div><div>I freely admit this is a non-technical thing, I just think it helps send the correct message.</div><div><br></div><div>Also, as I said, I'm very sympathetic to the desire to support existing users of the existing name. I think we should at least either make it configurable or install symlinks under the old name... I actually think we should probably do *both*.</div></div></div>
</blockquote></div><br></div><div class="gmail_extra"><br></div>To be done simultaneously or can we stage them so that the name change is checked in *after* we stabilize the overall build and switch-over to openmp? I would hate to see things delayed over this when we have ages to switch the name before the 3.7 release. Also, might you not want to take that time for a more in-depth discussion about any changes related to so versioning? Do we expect to always just be able to use the same shared library name or will we have to explicitly version it for possible ABI changes later on. If we expect the existing ABI to never change but only see additions to the ABI as OpenMP 4.0 support is added, I guess that isn't an issue. Perhaps such issues should be digested for awhile before jumping to a shared library name change.<div><br></div></div>