[LLVMdev] libiomp, not libgomp as default library linked with -fopenmp

[Richard Smith]

On Fri, May 1, 2015 at 11:36 AM, C Bergström <cbergstrom at pathscale.com>
wrote:

> On Sat, May 2, 2015 at 1:31 AM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > 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 wish people who haven't been involved with the development wouldn't
> get hung-up on the name.


No hang-ups here, just, as noted, bikeshedding.


> It's not user facing and the "branding"
> doesn't really matter. (Do you really feel that strongly about this?)
>

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.

Having the build time configure option makes this irrelevant and then
> whoever is packaging it can name it whatevere they want.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/d5c7e0ae/attachment.html>