[cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp

[Chandler Carruth]

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.

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.

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.

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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150612/93e20623/attachment.html>