[cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp

Richard Smith richard at metafoo.co.uk
Tue Jun 23 16:45:49 PDT 2015 

On Tue, Jun 23, 2015 at 3:16 PM, Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:

> Richard,
>       Please try linux again with current openmp trunk and the
> proposed cmake overhaul changes from...
>
> http://reviews.llvm.org/D10656
>
> using the patch at...
>
>
> http://reviews.llvm.org/file/data/yelxztueytythwycxwjx/PHID-FILE-m5boinw4uugif7ky6tpq/D10656.diff
>
> applied.
>

Done. The CMP0040 is gone, and I still get a working libomp.so. However,
some of the libomp-micro-tests checks don't pass:

libomp-test-touch fails because it sets LD_LIBRARY_PATH to include
[...]/build/projects/openmp/runtime/src, rather than the correct path
[...]/build/lib

libomp-test-instr fails with "check-instruction-set.pl: (x) Only works on
lin_32 and lin_mic platforms."


>                Jack
>
> On Tue, Jun 23, 2015 at 6:10 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > 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/11a5cdd3/attachment.html>

More information about the cfe-dev mailing list