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

[Alp Toker]

On 20/02/2014 13:39, Andrey Bokhanko wrote:
> Hi Chandler,
>
> I agree with most of your libiomp concerns. However, I wonder why they 
> haven't been raised before? Also, I guess openmp-dev mailing list 
> (http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev) is the proper 
> place to raise them.

Chandler raises some good points but there's nothing that can't be fixed 
here.

I've made a start to tidy things up in the openmp SVN module, r202018 
and will be trying to get a feel for it to see if the project can 
integrate better, working on the assumption that ToT is the current 
latest code base (if not, all bets are off).

>
> As for
>
>     - This library is not being developed as an active part of the
>     LLVM community, even if it is checked into SVN as part of the LLVM
>     project and under its license. See r197914 where there is a code
>     drop of many months worth of development with *no* change log,
>     attribution, information, or other participation in any part of
>     the community.
>     - There has been essentially *zero* discussion with the rest of
>     the clang or llvm community about this library. There are separate
>     mailing lists which have nearly no traffic since the code drop.
>
>
> the answer is very simple: apparently, very few people in the 
> community care for OpenMP in clang and are willing to contribute their 
> time and efforts into further development.

This isn't necessarily a problem. LLVM developers can and do contribute 
towards subprojects that they don't actively use all the time.

Contributions might be in the form of fixes for programming errors, 
build system integration and synergy with the clang frontend so it's 
always worth opening up and inviting more work.

>
> You are welcome to join at any point! -- and make openmp-dev list 
> non-empty. Again, your concerns is a good start -- I'm actually they 
> glad that you posted them.


My suggestion as a first course of action is that the openmp-commits and 
openmp-dev lists can be folded into either the llvm or clang lists until 
such time that the volume becomes a burden.

This is already done with other submodules and increases visibility for 
code review. When work is seen to be done others will gain interest and 
contribute regardless of whether they have an actual need for an OpenMP 
runtime library. Enthusiasm for development in LLVM is contagious :-)

>
> As for
>
>     Today, when users get Clang on Linux, they likely already have
>     libgomp installed much as they have libstdc++ installed. We don't
>     even vaguely document how to build or install libiomp5, much less
>     is that common practice when installing a Clang and LLVM based
>     toolchain. As such, this essentially regresses every user if
>     -fopenmp on Linux.
>
>
> This is really bizarre.
>
> libgomp dependency was introduced with no code review whatsoever 
> (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130114/072077.html), 
> serves very limited set of users

It is limited but Chandler's change seems to be on the acceptable side 
of of what constitutes a post-commit review. If anything, it'd be nice 
to see more of that kind of development happen on the openmp SVN module. 
That's why I'm recommending to fold the OpenMP commits and development 
lists into one of the parent projects for the time being.

Alp.


> (those who use clang on Linux *and* use a compiler with no OpenMP 
> support for OpenMP programs *and* directly call libgomp API *and* 
> started to do all this staff since clang 3.3, not before), uses a 
> library not readily available on Darwin, uses a GPL-licensed library 
> while a BSD-licensed one is available and interferes with OpenMP 
> support development (as it relies on Intel OMP API that libgomp 
> doesn't support).
>
> IMHO, the sooner this dependency will be eliminated, the better.
>
> Alternatively, Hal's suggestion 
> (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/099500.html) 
> makes sense for me.
>
> Yours,
> Andrey
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-- 
http://www.nuanti.com
the browser experts