[cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp

Chandler Carruth chandlerc at google.com
Mon Jun 22 23:12:19 PDT 2015 

On Fri, Jun 12, 2015 at 10:19 AM Peyton, Jonathan L <
jonathan.l.peyton at intel.com> wrote:

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

When I re-testing things, I still saw some things in the cache. Not sure if
that was staleness or on-going issues.

Anyways, I suspect the most productive thing is to focus on your re-work
patch which I'll look at. As I said before, I strongly believe that is the
best path forward.


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

More information about the cfe-dev mailing list