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

[Hal Finkel]

----- 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