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

Thu Apr 30 08:10:31 PDT 2015

I definitely support Andrey’s proposal to move the default to libiomp.  Outside of the known ports for x86, ARM and PowerPC, I’m aware of at least one other port in progress.  More will likely follow.  

Per Hal’s notes, given the forthcoming commits of the CMake build system, flipping the default to libiomp may help spur/accelerate the progress of porting the runtime to new platforms (especially those that are already supported as LLVM backends).   

--John D. Leidel

On Apr 30, 2015, at 9:06 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> From: "Andrey Bokhanko" <andreybokhanko at gmail.com>
>> To: "cfe-dev" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Douglas Gregor"
>> <dgregor at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "C Bergström" <cbergstrom at pathscale.com>, "Michael Wong"
>> <fraggamuffin at gmail.com>, "Alexey Bataev" <a.bataev at gmx.com>
>> Sent: Thursday, April 30, 2015 8:49:30 AM
>> Subject: libiomp, not libgomp as default library linked with -fopenmp
>> 
>> 
>> All,
>> 
>> 
>> I'd like to resurrect the discussion on replacing libgomp with
>> libiomp as the default OpenMP runtime library linked with -fopenmp.
>> 
>> 
>> For reference, the previous discussion is accessible there:
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140217/thread.html#99461
>> 
>> 
>> 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.
> 
> To be clear, this is now LLVM's OpenMP runtime (not just Intel's), and has been ported to several platforms in addition to x86 (PowerPC, ARM).
> 
>> 
>> 
>> Last time Chandler objected against doing this, and gave a good (and
>> proper!) scolding. Let me quote his objections along with updates on
>> current state of things:
>> 
>> 
>> 
>> 
>> - 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.
>> 
>> 
>> 
>> 
>> Now it is actively developed by several members of the community.
>> Changes are committed in small patches. See "openmp-commits" mailing
>> list ( http://lists.cs.uiuc.edu/pipermail/openmp-commits/ ) for
>> details.
>> 
>> 
>> 
>> 
>> - 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.
>> 
>> 
>> 
>> 
>> Nowadays the traffic, while less than on llvm-dev mailing list
>> (understandably so :-)) is far from being "zero". Discussions happen
>> all the time. See the list archives for details (
>> http://lists.cs.uiuc.edu/pipermail/openmp-dev/ ).
>> 
>> 
>> 
>> 
>> - 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.
>> 
>> 
>> 
>> 
>> This is fixed.
>> 
>> 
>> 
>> 
>> - 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.
>> 
>> 
>> 
>> 
>> The build system is full re-written and now cmake-based. The last
>> remaining step (integration into overall llvm build system) is about
>> to be done by any day now (
>> http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-April/thread.html#500
>> ).
>> 
>> 
>> 
>> 
>> - There are *zero tests* in the open source repository!!!! This is
>> even called out in the original submission and on the primary
>> website. We simply *cannot* ship and link against a runtime library
>> which has no tests!
>> 
>> 
>> 
>> 
>> UofHouston contributed a comprehensive test suite:
>> http://llvm.org/viewvc/llvm-project/openmp/trunk/testsuite/ .
>> 
>> 
>> 
>> 
>> - No part of this library has gone through an LLVM release process
>> either, not even as a "new" or "beta" project.
>> 
>> 
>> 
>> 
>> The whole library is a part of two last llvm releases: 3.5 and 3.6.
>> 
>> 
>> 
>> 
>> Thus, I believe all of Chandler's concerns are resolved, and it is
>> finally a good time time to switch to libiomp as default OpenMP
>> library.
>> 
>> 
>> 
>> 
>> Anyone who supports this?
>> 
> 
> I support this. Linking to libgomp will still be available by specifying -fopenmp=libgomp for those who need it. Our runtime supports a libgomp-compatible interface, so that's hopefully not necessary even for those with GCC-compiled OpenMP object files and libraries.
> 
> We need to get the build system integration committed and the buildbots updated to compile it, and the test suite setup (the build system integration and test-suite setup have patches under review on the openmp list, so I suspect this will happen soon). Practically, since we don't have OpenMP in the test suite (yet), none of these are really inflexible prerequisites. In my opinion, as soon as the build system integration is done (so that people have an easy way to use LLVM's runtime), we should flip the defaults -- the other things will follow shortly.
> 
> -Hal
> 
>> 
>> 
>> 
>> Anyone who disagrees?
>> 
>> 
>> 
>> 
>> Chandler?
>> 
>> 
>> Yours,
>> Andrey Bokhanko
>> ==============
>> Software Engineer
>> Intel Compiler Team
>> Intel
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev