[cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp
Peyton, Jonathan L
jonathan.l.peyton at intel.com
Fri Jun 12 10:19:38 PDT 2015
>
> For example, it defines at global scope a reasonably large number of
> variables like "os", "arch" and friends.
>
Can you please point out what you are talking about here. I have prefixed all the CACHED variables with LIBOMP_. These variables are now LIBOMP_OS, LIBOMP_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.
Yes, I have been working on cmake/config-ix.cmake for libomp, it is almost complete. But I completely agree this has to conform to the conventional LLVM style of having cmake/config-ix.cmake do compiler flag checks, library checks, feature checks, etc.
-- Johnny
-----Original Message-----
From: Jack Howarth [mailto:howarth.mailing.lists at gmail.com]
Sent: Friday, June 12, 2015 7:26 AM
To: Chandler Carruth
Cc: Richard Smith; cfe-dev; Peyton, Jonathan L; Andrey Bokhanko; Alexey Bataev
Subject: Re: [cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp
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-20
>> >> >> > 150525/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