[cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp

Chandler Carruth chandlerc at google.com
Mon Jun 22 23:15:50 PDT 2015 

On Mon, Jun 22, 2015 at 5:11 PM Jack Howarth <
howarth.mailing.lists at gmail.com> wrote:

>    From the posting of the 3.7svn release schedule at...
>
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043595.html
>
> it really seems like the time has arrived to decide if the new
> -fopenmp=libomp support will be the default for the 3.7 release.
>             Jack
>

Our releases are time based, not feature based. And we shouldn't turn on
features until they're ready, regardless of whether it's convenient to the
release schedule.


> ps IMHO as an end-user, it seems pretty idiotic to disable it in favor
> of a completely non-op version of -fopenmp=libgomp.
>

You seem to ignore the fact that there are lots of other end-users, some of
which are represented by myself or others, and some of which have and
continue to use libgomp as a functional if no-op implementation. =/

I don't think characterizing this as "idiotic" is productive at all. I
think it would be much more productive to help contribute patches to
improve things than to criticize those who do. =/ I'm personally going to
focus on reviewing Jonathan's patches instead of continuing this thread.


>
> On Fri, Jun 12, 2015 at 1:19 PM, 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.
> >
> >> 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/fc3359d2/attachment.html>

More information about the cfe-dev mailing list