<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 12, 2015 at 10:19 AM Peyton, Jonathan L <<a href="mailto:jonathan.l.peyton@intel.com">jonathan.l.peyton@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">><br>
> For example, it defines at global scope a reasonably large number of<br>
> variables like "os", "arch" and friends.<br>
><br>
<br>
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.<br></blockquote><div><br></div><div>When I re-testing things, I still saw some things in the cache. Not sure if that was staleness or on-going issues.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Another example is that it uses a completely novel way of managing<br>
> compiler flags compared to all of LLVM, Clang, CompilerRT, libc++, and<br>
> libc++abi. I have to think that even if some of these don't apply, at<br>
> least one does. In particular, the openmp runtime seems to have almost<br>
> identical needs for configuration as the libc++ runtime library, with<br>
> the possible exception of needing to run an assembler.<br>
<br>
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.<br>
<br>
-- Johnny<br>
<br>
-----Original Message-----<br>
From: Jack Howarth [mailto:<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>]<br>
Sent: Friday, June 12, 2015 7:26 AM<br>
To: Chandler Carruth<br>
Cc: Richard Smith; cfe-dev; Peyton, Jonathan L; Andrey Bokhanko; Alexey Bataev<br>
Subject: Re: [cfe-dev] switching CLANG_DEFAULT_OPENMP_RUNTIME to libomp<br>
<br>
On Fri, Jun 12, 2015 at 12:06 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br>
> I've had time to check, and a large amount of my concerns over the<br>
> openmp CMake build have not been addressed.<br>
><br>
> For example, it defines at global scope a reasonably large number of<br>
> variables like "os", "arch" and friends.<br>
><br>
<br>
Chandler,<br>
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 <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__build.pl&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=R795UiCIMMCZ1L1BcvfaNeAGPGNRHfhZ37Oxk9LhHr8&s=awW-fo3NnnW73B5Nm5hVSeY8Fklm6KYjaPQNXsCajlU&e=" rel="noreferrer" target="_blank">build.pl</a> 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 <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__build.pl&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=R795UiCIMMCZ1L1BcvfaNeAGPGNRHfhZ37Oxk9LhHr8&s=awW-fo3NnnW73B5Nm5hVSeY8Fklm6KYjaPQNXsCajlU&e=" rel="noreferrer" target="_blank">build.pl</a> system.<br>
<br>
> Another example is that it uses a completely novel way of managing<br>
> compiler flags compared to all of LLVM, Clang, CompilerRT, libc++, and<br>
> libc++abi. I have to think that even if some of these don't apply, at<br>
> least one does. In particular, the openmp runtime seems to have almost<br>
> identical needs for configuration as the libc++ runtime library, with<br>
> the possible exception of needing to run an assembler.<br>
><br>
<br>
Again some of this may be a fall-out of the migration of the build system from <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__build.pl&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=R795UiCIMMCZ1L1BcvfaNeAGPGNRHfhZ37Oxk9LhHr8&s=awW-fo3NnnW73B5Nm5hVSeY8Fklm6KYjaPQNXsCajlU&e=" rel="noreferrer" target="_blank">build.pl</a> to cmake. It might help if you listed specific examples of the flags you wanted to be standardized.<br>
<br>
> I also don't see any way to run any of the OpenMP tests using the<br>
> CMake build, but maybe I'm just missing it.<br>
<br>
The cmake support for running the test suite is in fact missing but shouldn't be hard for Jeremy to implement.<br>
Jack<br>
<br>
><br>
> I'll repeat what I said previously in the other thread: I think that<br>
> the OpenMP CMake build should be replaced with one that functions<br>
> essentially the same way as the libc++ CMake build, including the use<br>
> of 'lit' to drive the test suite. libc++ has extremely similar build<br>
> configuration and testsuite needs, and so I feel like we shouldn't<br>
> have two radically different ways of doing everything within the same<br>
> project. It makes the maintenance burden for those of us that work on<br>
> the larger LLVM project's CMake support much, much higher. Perhaps a<br>
> detailed explanation of why that isn't feasible or reasonable?<br>
><br>
> On Thu, Jun 11, 2015 at 8:45 PM Jack Howarth<br>
> <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>><br>
>> Richard,<br>
>> I do my local build using tarballs generated from current trunk<br>
>> svn pulls. The rough formula I use (after these are extracted) are...<br>
>><br>
>> cd llvm-3.7.0.src<br>
>> mv ../cfe-3.7.0.src tools/clang<br>
>> mv ../compiler-rt-3.7.0.src projects/compiler-rt mv<br>
>> ../libcxx-3.7.0.src projects/libcxx mv ../openmp-3.7.0.src<br>
>> projects/openmp mv ../polly-3.7.0.src tools/polly mv<br>
>> ../clang-tools-extra-3.7.0.src tools/clang/tools/extra mkdir build cd<br>
>> build cmake -DLLVM_BUILD_32_BITS:BOOL=OFF -DLLVM_TARGETS_TO_BUILD=X86<br>
>> \<br>
>> -DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_BUILD_TYPE=Release<br>
>> -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386" \<br>
>> -DCMAKE_OSX_SYSROOT:STRING=/<br>
>> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" \<br>
>> -DLLVM_ENABLE_LIBCXX=ON -DLIBCXX_LIBCPPABI_VERSION=""<br>
>> -DENABLE_CLANG_OPENMP=ON ..<br>
>> make VERBOSE=1<br>
>><br>
>> This builds the libomp.dylib as a fat binary on x86_64 darwin (for<br>
>> both i386/x86_64 support).<br>
>> I always execute "perl -pi -e 's|libgomp|libomp|g' CMakeLists.txt" in<br>
>> tools/clang before the build to switch the -fopenmp default to<br>
>> libomp.<br>
>> Jack<br>
>><br>
>> On Thu, Jun 11, 2015 at 10:34 PM, Richard Smith<br>
>> <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><br>
>> wrote:<br>
>> > On Thu, Jun 11, 2015 at 7:26 PM, Jack Howarth<br>
>> > <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On Thu, Jun 11, 2015 at 9:34 PM, Richard Smith<br>
>> >> <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><br>
>> >> wrote:<br>
>> >> > On Thu, Jun 11, 2015 at 4:58 PM, Jack Howarth<br>
>> >> > <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> Chandler,<br>
>> >> >> It has been over 10 days with no response (3 more than<br>
>> >> >> you used to justify reverting the libiomp5 default for<br>
>> >> >> -fopenmp). What blockers remain in current cfe/openmp svn which<br>
>> >> >> would prevent the default for -fopenmp from being switched over<br>
>> >> >> to libomp?<br>
>> >> ><br>
>> >> ><br>
>> >> > From my prior email these were the steps:<br>
>> >> ><br>
>> >> > "1) Reach the point where the openmp runtime library can be<br>
>> >> > checked out into a normal llvm / clang build tree (into<br>
>> >> > projects/openmp, perhaps) and it integrates properly into the<br>
>> >> > build and builds successfully on various systems.<br>
>> >> > 2) Update the clang "getting started" documentation to suggest<br>
>> >> > doing this if the user wants OpenMP support<br>
>> >> > (changehttp://<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_get-5Fstarted.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=R795UiCIMMCZ1L1BcvfaNeAGPGNRHfhZ37Oxk9LhHr8&s=43WETTZnN6eso-WZ03UsGEMHBshIHeTvaN6ctkYhQrY&e=" rel="noreferrer" target="_blank">clang.llvm.org/get_started.html</a><br>
>> >> > to say what to check out and where -- no steps other than an 'svn co'<br>
>> >> > should<br>
>> >> > be necessary).<br>
>> >> > 3) Change the default for CLANG_DEFAULT_OPENMP_RUNTIME to libomp<br>
>> >> > (possibly conditioned on a "is libomp part of this build?"<br>
>> >> > test)."<br>
>> >> ><br>
>> >> > Step 2 has certainly not happened. Has step 1 happened?<br>
>> >><br>
>> >> I have been building current openmp in the llvm/projects/openmp<br>
>> >> location as a cmake build on x86_64-apple-darwin14 daily without<br>
>> >> issues. So step 1 is complete on darwin.<br>
>> ><br>
>> ><br>
>> > If you can let me know what I should check out where, I'll be happy<br>
>> > to test it on Linux for you. (Should I check out<br>
>> > <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_svn_llvm-2Dproject_openmp_trunk_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=R795UiCIMMCZ1L1BcvfaNeAGPGNRHfhZ37Oxk9LhHr8&s=DpYTaG1Ocg7ynxNqywg2n2vuHDQK0U9bvAUyU2LKPmg&e=" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/openmp/trunk/</a> or just the runtime/<br>
>> > subdirectory there?)<br>
>> ><br>
>> > It looks like the openmp directory is not listed in llvm's<br>
>> > projects/CMakeLists.txt, so there may be some more integration work<br>
>> > required for this to integrate properly into the llvm/clang build.<br>
>> ><br>
>> >> >> Jack<br>
>> >> >><br>
>> >> >> On Mon, Jun 1, 2015 at 7:34 AM, Jack Howarth<br>
>> >> >> <<a href="mailto:howarth.mailing.lists@gmail.com" target="_blank">howarth.mailing.lists@gmail.com</a>> wrote:<br>
>> >> >> > Chandler,<br>
>> >> >> > Now that openmp trunk is producing the desired renamed<br>
>> >> >> > libomp shared library by default and a libgomp symlink to it<br>
>> >> >> > for use by -fopenmp=libgomp, do you have any remaining<br>
>> >> >> > objections to switching CLANG_DEFAULT_OPENMP_RUNTIME from<br>
>> >> >> > libgomp to libomp?<br>
>> >> >> > Jack<br>
>> >> >> > ps As the recent posting in cfe-commits indicates....<br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20</a><br>
>> >> >> > 150525/130067.html<br>
>> >> >> ><br>
>> >> >> > the absence of complaints about the previous -fopenmp=libgomp<br>
>> >> >> > default may be more due to misconceptions about the level of<br>
>> >> >> > support for OpenMP that provides rather than any real desire<br>
>> >> >> > to use it in place of the LLVM openmp (which is completely<br>
>> >> >> > functional).<br>
>> >> >> _______________________________________________<br>
>> >> >> cfe-dev mailing list<br>
>> >> >> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> >> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
</blockquote></div></div>