<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jun 22, 2015 at 5:11 PM Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> From the posting of the 3.7svn release schedule at...<br>
<br>
<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043595.html" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043595.html</a><br>
<br>
it really seems like the time has arrived to decide if the new<br>
-fopenmp=libomp support will be the default for the 3.7 release.<br>
Jack<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ps IMHO as an end-user, it seems pretty idiotic to disable it in favor<br>
of a completely non-op version of -fopenmp=libgomp.<br></blockquote><div><br></div><div>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. =/</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Fri, Jun 12, 2015 at 1:19 PM, Peyton, Jonathan L<br>
<<a href="mailto:jonathan.l.peyton@intel.com" target="_blank">jonathan.l.peyton@intel.com</a>> wrote:<br>
>><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>
><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=57IOdH5cijPNZ0DxsW-9vrZZW5Gu3b3w8BSh5xGl6_A&s=T979ORwQGfDdgUpWr7noKBJ508aFJUyyHxdrBsD48_8&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=57IOdH5cijPNZ0DxsW-9vrZZW5Gu3b3w8BSh5xGl6_A&s=T979ORwQGfDdgUpWr7noKBJ508aFJUyyHxdrBsD48_8&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=57IOdH5cijPNZ0DxsW-9vrZZW5Gu3b3w8BSh5xGl6_A&s=T979ORwQGfDdgUpWr7noKBJ508aFJUyyHxdrBsD48_8&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=57IOdH5cijPNZ0DxsW-9vrZZW5Gu3b3w8BSh5xGl6_A&s=3DzQRTiqSg6Dq-FylZoHJXz2OEZJYPcIbIUXeLG1KYU&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=57IOdH5cijPNZ0DxsW-9vrZZW5Gu3b3w8BSh5xGl6_A&s=1Det4eXVsExyKaUyZLH2eW51oZaYwoVBu0AWqNzM2Hs&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>