[PATCH] [OPENMP] Replace libgomp by libiomp5 in driver

[Andrey Bokhanko]

+1

Yours,
Andrey


On Thu, Feb 20, 2014 at 4:32 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Chandler Carruth" <chandlerc at google.com>
> > To: "C. Bergström" <cbergstrom at pathscale.com>
> > Cc: reviews+D2841+public+0d4390c49e3f0815 at llvm-reviews.chandlerc.com,
> "Douglas Gregor" <dgregor at apple.com>, "Hal
> > Finkel" <hfinkel at anl.gov>, "Dmitri Gribenko" <gribozavr at gmail.com>,
> fraggamuffin at gmail.com, "a bataev"
> > <a.bataev at hotmail.com>, "llvm cfe" <cfe-commits at cs.uiuc.edu>
> > Sent: Thursday, February 20, 2014 5:15:54 AM
> > Subject: Re: [PATCH] [OPENMP] Replace libgomp by libiomp5 in driver
> >
> >
> >
> >
> >
> > On Thu, Feb 20, 2014 at 2:57 AM, "C. Bergström" <
> > cbergstrom at pathscale.com > wrote:
> >
> >
> >
> > On 02/20/14 05:43 PM, Chandler Carruth wrote:
> >
> >
> >
> > - There has been no effort to make this library even work properly
> > with Clang as a host compiler. See the copious notes that only Clang
> > 3.3 is supported, and that not full featured.
> > - The build system is totally disjoint from LLVM's, in fact it is an
> > entirely custom Perl build system that is unlike anything in use by
> > the LLVM project.
> > We have some changes which should allow building with clang and also
> > cmake build files to resolve a couple of your issues. I planned to
> > create a pull request for Intel in the near future.
> >
> >
> > I so don't get this.
> >
> >
> > The project is no longer an Intel project. It is an LLVM project. The
> > development *must* take place as an LLVM project, or nothing else
> > will matter.
> >
> >
> > You could help formulate this process by submitting patches to the
> > LLVM project and committing them there. That *needs* to be the
> > upstream to make this a real, viable, open source effort.
> >
> >
> > This should help make QA'ing libiomp5 easier.
> >
> >
> >
> > This, of course, will be awesome. I look forward to better
> > documentation as well to clarify how to QA it. And tests with which
> > to QA it.
> >
> >
> > ----------
> > While I agree with all your points - pragmatically there is probably
> > very few real world clang + OMP users and the risk/impact is low.
> >
> >
> > This is simply false. I don't know why you think this. People here
> > have been using -fopenmp since the day they could link their
> > binaries which called out to an omp runtime library call. Yes, their
> > pragmas don't do anything, and their parallelism is terrible, but
> > they really are critically relying on the ability to build, link,
> > and execute (single threaded) programs with -fopenmp. Regressing a
> > documented and readily available feature of Clang with no warning
> > and no prior release cycle where these pieces were QA'ed and
> > released is pretty... bad.
> >
> >
> > I'd +1 this change since libiomp5 aligns with those who are actually
> > working on the code, using it and reviewing it.
> > I've not seen how this aligns with Dmitri or Doug's usages and I
> > think they've done essentially all of the review. I know it doesn't
> > align with any of my users that are relying on -fopenmp not
> > producing a link error.
>
> I agree that changing the default at this point is premature; there are
> users following trunk who rely on the existing behavior, and they'll see no
> benefit from the current change. On the other hand, we need the ability to
> link against our own runtime library in order to start adding CodeGen
> support, so we do need this change, it just does not need to be the default
> yet.
>
> Why don't we add a -fopenmp-lib=[gomp|iomp] or -fopenmp-type or flavor or
> whatever (I don't have a strong opinion about the naming), and base things
> off of that? In the future, we can change the default, and we can leave
> CodeGen support disabled when not targeting our own runtime.
>
>  -Hal
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140220/fd4bfd0a/attachment.html>