<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 1, 2015 at 11:36 AM, C Bergström <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, May 2, 2015 at 1:31 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> On Thu, Apr 30, 2015 at 2:51 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
> wrote:<br>
>><br>
>> On Thu, Apr 30, 2015 at 6:52 AM Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com">andreybokhanko@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> All,<br>
>>><br>
>>> I'd like to resurrect the discussion on replacing libgomp with libiomp as<br>
>>> 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>
>>> We are very close to getting *full* OpenMP 3.1 specification supported in<br>
>>> clang (only one (!) clause is not implemented yet, and the patch is already<br>
>>> sent for review today: <a href="http://reviews.llvm.org/D9370" target="_blank">http://reviews.llvm.org/D9370</a>). This implementation<br>
>>> generates Intel API library calls; thus, it can't be used with libgomp and<br>
>>> it is simply logical to link a compatible runtime (libiomp) instead.<br>
>><br>
>><br>
>> Is there no way to support libgomp here as well? I don't say this to hold<br>
>> up changing the defaults in any way, just curious. =]<br>
>><br>
>> Also, for the record, I'm really excited to see the progress here as well.<br>
>><br>
>>><br>
>>> Chandler?<br>
>><br>
>><br>
>> Hi! ;]<br>
>><br>
>> I totally agree, I think things are way better now. I generally support<br>
>> the direction. I think there are a few things I'd suggest we do as part of<br>
>> the process, but I think these are really small and just about "how" we<br>
>> switch.<br>
>><br>
>> 1) I completely agree with the comments some others have made about us<br>
>> needing to make it clear that this isn't some Intel-only thing, its the LLVM<br>
>> OpenMP runtime. Some suggestions that I think would 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 makes<br>
>> sense, awesome.<br>
>> - Clearly updating the readme and such would be appropriate.<br>
>> - I suspect we should change the name of the installed library. 'libiomp'<br>
>> is pretty clearly the Intel library. We could continue in the grand<br>
>> tradition of LLVM naming conventions and use 'libllomp'? Of course, we<br>
>> should install symlinks under the name 'libiomp' if needed for existing<br>
>> users to not be broken.<br>
><br>
><br>
> Just some bikeshed-painting: if we're expecting each compiler that uses the<br>
> library to distribute a separate copy as part of that compiler's runtime,<br>
> then I think the best name for clang to use for the library would probably<br>
> be libclang_rt.omp-<arch> or libclang_rt.openmp-<arch> (as we do for all our<br>
> other runtime libraries). If we expect this to be installed somewhere<br>
> central on the system and shared by different compilers and different<br>
> versions of the same compiler, then libllomp or similar seems reasonable to<br>
> me. What's the intended distribution model here? How stable is the ABI?<br>
<br>
</div></div>I wish people who haven't been involved with the development wouldn't<br>
get hung-up on the name.</blockquote><div><br></div><div>No hang-ups here, just, as noted, bikeshedding.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's not user facing and the "branding"<br>
doesn't really matter. (Do you really feel that strongly about this?)<br></blockquote><div><br></div><div>Chandler has a point that calling it libiomp makes it sound like an intel library, which isn't appropriate for an LLVM subproject. Beyond that, I don't really care, but it is something we should discuss and decide.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having the build time configure option makes this irrelevant and then<br>
whoever is packaging it can name it whatevere they want.<br></blockquote><div><br></div><div>The LLVM project also acts as a packager for people downloading our release tarballs. So we need to decide what we want to call this, as packagers.</div></div></div></div>