[cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp

Richard Smith richard at metafoo.co.uk
Tue Jun 23 15:10:11 PDT 2015 

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
>

You will probably need to explicit support for checking out openmp here to
llvm/projects/CMakeLists.txt, in order to get the "same as libcxx" behavior
that Chandler is requesting.


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

As promised, I tried this out on a Linux machine. Here's what I did:

 * check out all the pieces, including putting
http://llvm.org/svn/llvm-project/openmp/trunk/ into llvm/projects/openmp
 * run cmake without specifying any special flags (this should "just work")
 * build
 * run clang from build area and test

Here's what I got:

# From cmake:

CMake Warning (dev) at projects/openmp/runtime/src/CMakeLists.txt:26
(add_custom_command):
  Policy CMP0040 is not set: The target in the TARGET signature of
  add_custom_command() must exist.  Run "cmake --help-policy CMP0040" for
  policy details.  Use the cmake_policy command to set the policy and
  suppress this warning.

  The target name "common" is unknown in this context.

It looks like the cmake build is not correctly configured here. I'm not
sure whether these custom commands are the right way to handle these header
files, but the TARGET should presumably be "libomp-common" or "libomp-mod",
not just "common" or "mod". I assume this will be fixed by the cmake build
system rework.

# From build:

*Lots* of warnings, but a successful build. These warnings should be fixed
(or, where appropriate, suppressed), but I don't personally think that
needs to be a prerequisite for changing the default value of -fopenmp=.

# From running Clang with -fopenmp=libomp:

Everything I tested works fine (the not-yet-installed library is not found,
but that seems like the right behaviour if we expect this library to live
in /usr/lib rather than in a compiler-specific library area). However, I
couldn't find a make target to run the libomp tests, and I couldn't find a
target to install the libomp runtime.

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/20150623/de8be625/attachment.html>

More information about the cfe-dev mailing list