[cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp

[Jack Howarth]

On Fri, Jun 12, 2015 at 12:06 AM, Chandler Carruth <chandlerc at google.com> wrote:
> I've had time to check, and a large amount of my concerns over the openmp
> CMake build have not been addressed.
>
> For example, it defines at global scope a reasonably large number of
> variables like "os", "arch" and friends.
>

Chandler,
       This is likely residue from the conversion of the original
build.pl-based build
system to the cmake build system. My understanding is that the cmake
build system
still uses some of the .pl scripts from the legacy build.pl build
system. So some of
the renaming may have to be postponed until the openmp cmake system is totally
purged of any remnants of the old build.pl system.

> Another example is that it uses a completely novel way of managing compiler
> flags compared to all of LLVM, Clang, CompilerRT, libc++, and libc++abi. I
> have to think that even if some of these don't apply, at least one does. In
> particular, the openmp runtime seems to have almost identical needs for
> configuration as the libc++ runtime library, with the possible exception of
> needing to run an assembler.
>

Again some of this may be a fall-out of the migration of the build system from
build.pl to cmake. It might help if you listed specific examples of
the flags you
wanted to be standardized.

> I also don't see any way to run any of the OpenMP tests using the CMake
> build, but maybe I'm just missing it.

The cmake support for running the test suite is in fact missing but shouldn't
be hard for Jeremy to implement.
                  Jack

>
> I'll repeat what I said previously in the other thread: I think that the
> OpenMP CMake build should be replaced with one that functions essentially
> the same way as the libc++ CMake build, including the use of 'lit' to drive
> the test suite. libc++ has extremely similar build configuration and
> testsuite needs, and so I feel like we shouldn't have two radically
> different ways of doing everything within the same project. It makes the
> maintenance burden for those of us that work on the larger LLVM project's
> CMake support much, much higher. Perhaps a detailed explanation of why that
> isn't feasible or reasonable?
>
> On Thu, Jun 11, 2015 at 8:45 PM Jack Howarth
> <howarth.mailing.lists at gmail.com> wrote:
>>
>> Richard,
>>       I do my local build using tarballs generated from current trunk
>> svn pulls. The rough formula I use (after these are extracted) are...
>>
>> cd llvm-3.7.0.src
>> mv ../cfe-3.7.0.src tools/clang
>> mv ../compiler-rt-3.7.0.src projects/compiler-rt
>> mv ../libcxx-3.7.0.src projects/libcxx
>> mv ../openmp-3.7.0.src projects/openmp
>> mv ../polly-3.7.0.src tools/polly
>> mv ../clang-tools-extra-3.7.0.src tools/clang/tools/extra
>> mkdir build
>> cd build
>> cmake -DLLVM_BUILD_32_BITS:BOOL=OFF -DLLVM_TARGETS_TO_BUILD=X86 \
>>             -DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_BUILD_TYPE=Release
>> -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386" \
>>             -DCMAKE_OSX_SYSROOT:STRING=/
>> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" \
>>             -DLLVM_ENABLE_LIBCXX=ON -DLIBCXX_LIBCPPABI_VERSION=""
>> -DENABLE_CLANG_OPENMP=ON ..
>> make VERBOSE=1
>>
>> This builds the libomp.dylib as a fat binary on x86_64 darwin (for
>> both i386/x86_64 support).
>> I always execute "perl -pi -e 's|libgomp|libomp|g' CMakeLists.txt" in
>> tools/clang before the build to
>> switch the -fopenmp default to libomp.
>>              Jack
>>
>> On Thu, Jun 11, 2015 at 10:34 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>> > On Thu, Jun 11, 2015 at 7:26 PM, Jack Howarth
>> > <howarth.mailing.lists at gmail.com> wrote:
>> >>
>> >> On Thu, Jun 11, 2015 at 9:34 PM, Richard Smith <richard at metafoo.co.uk>
>> >> wrote:
>> >> > On Thu, Jun 11, 2015 at 4:58 PM, Jack Howarth
>> >> > <howarth.mailing.lists at gmail.com> wrote:
>> >> >>
>> >> >> Chandler,
>> >> >>       It has been over 10 days with no response (3 more than you
>> >> >> used
>> >> >> to justify reverting the libiomp5 default for -fopenmp). What
>> >> >> blockers
>> >> >> remain in current cfe/openmp svn which would prevent the default for
>> >> >> -fopenmp from being switched over to libomp?
>> >> >
>> >> >
>> >> > From my prior email these were the steps:
>> >> >
>> >> > "1) Reach the point where the openmp runtime library can be checked
>> >> > out
>> >> > into
>> >> > a normal llvm / clang build tree (into projects/openmp, perhaps) and
>> >> > it
>> >> > integrates properly into the build and builds successfully on various
>> >> > systems.
>> >> > 2) Update the clang "getting started" documentation to suggest doing
>> >> > this if
>> >> > the user wants OpenMP support
>> >> > (changehttp://clang.llvm.org/get_started.html
>> >> > to say what to check out and where -- no steps other than an 'svn co'
>> >> > should
>> >> > be necessary).
>> >> > 3) Change the default for CLANG_DEFAULT_OPENMP_RUNTIME to libomp
>> >> > (possibly
>> >> > conditioned on a "is libomp part of this build?" test)."
>> >> >
>> >> > Step 2 has certainly not happened. Has step 1 happened?
>> >>
>> >> I have been building current openmp in the llvm/projects/openmp
>> >> location as a cmake
>> >> build on x86_64-apple-darwin14 daily without issues. So step 1 is
>> >> complete on darwin.
>> >
>> >
>> > If you can let me know what I should check out where, I'll be happy to
>> > test
>> > it on Linux for you. (Should I check out
>> > http://llvm.org/svn/llvm-project/openmp/trunk/ or just the runtime/
>> > subdirectory there?)
>> >
>> > It looks like the openmp directory is not listed in llvm's
>> > projects/CMakeLists.txt, so there may be some more integration work
>> > required
>> > for this to integrate properly into the llvm/clang build.
>> >
>> >> >>                Jack
>> >> >>
>> >> >> On Mon, Jun 1, 2015 at 7:34 AM, Jack Howarth
>> >> >> <howarth.mailing.lists at gmail.com> wrote:
>> >> >> > Chandler,
>> >> >> >       Now that openmp trunk is producing the desired renamed
>> >> >> > libomp
>> >> >> > shared library by default and a libgomp symlink to it for use by
>> >> >> > -fopenmp=libgomp, do you have any remaining objections to
>> >> >> > switching
>> >> >> > CLANG_DEFAULT_OPENMP_RUNTIME from libgomp to libomp?
>> >> >> >               Jack
>> >> >> > ps As the recent posting in cfe-commits indicates....
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150525/130067.html
>> >> >> >
>> >> >> > the absence of complaints about the previous -fopenmp=libgomp
>> >> >> > default
>> >> >> > may be more due to misconceptions about the level of support for
>> >> >> > OpenMP that provides rather than any real desire to use it in
>> >> >> > place
>> >> >> > of
>> >> >> > the LLVM openmp (which is completely functional).
>> >> >> _______________________________________________
>> >> >> cfe-dev mailing list
>> >> >> cfe-dev at cs.uiuc.edu
>> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >> >
>> >> >
>> >
>> >