[PATCH] LLVM OpenMP CMake Overhaul
Peyton, Jonathan L
jonathan.l.peyton at intel.com
Tue Jun 23 10:04:03 PDT 2015
Chris,
> I am strongly apposed to this change. This was designed specifically to ensure that each set of compilers can easily set their own specific flags. Do not remove this feature.
>Why - who cares? fwiw - most cmake files are named CMakeLists.txt
> .cmake is typically used for cmake files which are meant to be reused as "modules".
> I am a bit annoyed with the history of the cmake build system. My original system worked and was removed without much justification "just because". Now it's being refactored again and it's unclear to me the driving motivation.
Maybe I can help answer these questions with the aid of the email message below. To get the LLVM OpenMP Runtime set as the default OpenMP runtime library linked when using the -fopenmp flag, we have to get our CMake build to use LLVM conventions/standards. This meant putting everything in its own pseudo namespace Libomp, libomp_ , or LIBOMP_ and creating a real configuration step which checks for compiler flags, features, etc. I've followed what libcxx and compiler-rt do by having a config-ix.cmake file which does all this. Although the compiler flags approach I had worked for gcc,clang,icc,and msvc, this method of checking the compiler flags is more generic and allows any compiler that supports the flag to use it. Also, there are at least three other methods of adding custom flags (-DLIBOMP_${LANG}FLAGS=' ... ' , -DCMAKE_${LANG}_FLAGS=' ... ' , or good ole CFLAGS=' ... ' envirable). The ultimate goal here is to get the LLVM OpenMP Runtime set as the default, so I have to do whatever it takes to achieve that. If I get the ok to keep the old compiler flag method, I will.
-- Johnny
-----Original Message-----
From: Jack Howarth [mailto:howarth.mailing.lists at gmail.com]
Sent: Friday, June 12, 2015 6:46 AM
To: Peyton, Jonathan L; Andrey Bokhanko; Alexey Bataev
Subject: Fwd: [cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp
---------- Forwarded message ----------
From: Chandler Carruth <chandlerc at google.com>
Date: Fri, Jun 12, 2015 at 12:06 AM
Subject: Re: [cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp
To: Jack Howarth <howarth.mailing.lists at gmail.com>, Richard Smith <richard at metafoo.co.uk>
Cc: cfe-dev <cfe-dev at cs.uiuc.edu>
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.
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.
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.
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-201
> >> >> > 50525/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
> >> >
> >> >
> >
> >
-----Original Message-----
From: C Bergström [mailto:cbergstrom at pathscale.com]
Sent: Tuesday, June 23, 2015 11:47 AM
To: reviews+D10656+public+dda1fdcafb4c32bf at reviews.llvm.org
Cc: Peyton, Jonathan L; Chandler Carruth; howarth.mailing.lists at apple.com; openmp-commits at dcs-maillist2.engr.illinois.edu; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] LLVM OpenMP CMake Overhaul
Is this patch updated to reflect my review comments?
Again some of your design changes remove features that are intentionally in the existing cmake by design. They should not be removed. It's essetial that we maintain a mechanism to allow each compiler the flexibility to define their own flags. Unlike other llvm projects, this library is very likely to be used standalone by others entirely outside the scope of llvm.
So do not remove cmake/${CMAKE_C_COMPILER_ID}/*Flags.cmake directories/files
On Tue, Jun 23, 2015 at 11:30 PM, Jonathan Peyton <jonathan.l.peyton at intel.com> wrote:
> Hi chandlerc,
>
> I have been working on overhauling the CMake build system for the LLVM OpenMP Runtime library. Instead of sending 1000 small updates, I decided to do a complete refactoring/reorganizing/renaming/you-name-it-I-did-it. **All the interface variables are still the same (LIBOMP_OS, LIBOMP_ARCH, etc.)**. So there was no change there. Here are the major changes:
> 1) Renaming internal variables/macros/functions – everything has libomp_ or LIBOMP_ prefixed to it unless maybe if it is a local variable/parameter inside a function/macro.
> 2) config-ix.cmake added – compiler flag checks, linker flag checks, some feature checks, threading-model check. This means cmake/${CMAKE_C_COMPILER_ID}/*Flags.cmake directories/files are deleted.
> 3) All files inside cmake/ subdirectory are renamed to Libompxyz.cmake
> 4) I cut off most of the vestigial parts that were a part of the translation of build.pl system. There are still a few that remain like LibompExports.cmake (copying things to exports/ subdirectory) and LibompMicroTests.cmake (small tests to run on the just created library. This is invoked with make libomp-micro-tests), but these can easily be cut off because they are in their own files and surrounded by an if() guard in the CMakeLists.txt file.
> 5) Added LLVM-architecture detection if we are part of an LLVM build.
> 6) If you want, you can use LIBOMP_ARCH=i386 or LIBOMP_ARCH=x86_64
> instead of LIBOMP_ARCH=32 or LIBOMP_ARCH=32e (although 32 and 32e
> still exist)
> 7) Unused functions/macros have been cut away.
>
> REPOSITORY
> rL LLVM
>
> http://reviews.llvm.org/D10656
>
> Files:
> runtime/CMakeLists.txt
> runtime/cmake/BuildPLRules.cmake
> runtime/cmake/Clang/AsmFlags.cmake
> runtime/cmake/Clang/CFlags.cmake
> runtime/cmake/CommonFlags.cmake
> runtime/cmake/Definitions.cmake
> runtime/cmake/GNU/AsmFlags.cmake
> runtime/cmake/GNU/CFlags.cmake
> runtime/cmake/GNU/FortranFlags.cmake
> runtime/cmake/GetArchitecture.cmake
> runtime/cmake/HelperFunctions.cmake
> runtime/cmake/Intel/AsmFlags.cmake
> runtime/cmake/Intel/CFlags.cmake
> runtime/cmake/Intel/FortranFlags.cmake
> runtime/cmake/LibompCheckFortranFlag.cmake
> runtime/cmake/LibompCheckLinkerFlag.cmake
> runtime/cmake/LibompDefinitions.cmake
> runtime/cmake/LibompExports.cmake
> runtime/cmake/LibompGetArchitecture.cmake
> runtime/cmake/LibompHandleFlags.cmake
> runtime/cmake/LibompMicroTests.cmake
> runtime/cmake/LibompSourceFiles.cmake
> runtime/cmake/LibompUtils.cmake
> runtime/cmake/MSVC/AsmFlags.cmake
> runtime/cmake/MSVC/CFlags.cmake
> runtime/cmake/MicroTests.cmake
> runtime/cmake/PerlFlags.cmake
> runtime/cmake/SourceFiles.cmake
> runtime/cmake/config-ix.cmake
> runtime/src/CMakeLists.txt
>
> EMAIL PREFERENCES
> http://reviews.llvm.org/settings/panel/emailpreferences/
More information about the llvm-commits
mailing list