[cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp
Jack Howarth
howarth.mailing.lists at gmail.com
Thu Jun 11 20:45:14 PDT 2015
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
>> >
>> >
>
>
More information about the cfe-dev
mailing list