- User Since
- Feb 19 2015, 6:37 AM (322 w, 1 d)
Oct 28 2015
The CMakeLists.txt change cited is in top-level of the clang sources and not in the llvm top-level.
The proposed patches here to change the default behavior of -fopenmp from -fopenmp=libgomp to -fopenmp=libomp seem to only handle the configure-based build. The following change required to switch over the crake-based build to default -fopenmp to libomp is missing.
Sep 22 2015
One other issue. It appears that the tolerances used in runtime/test/api/omp_get_wtime.c are too tight for OS X 10.11. With or without SIP enabled, I get a return code between 2 to 6 on that test. Opening it up to...
There is one issue with rL248211. On darwin, the check-libomp test suite run depends on DYLD_LIBRARY_PATH being passed along through make. This isn't true in El Capitan due to the System Integrity Protection pruning of DYLD_LIBRARY_PATH.
Can we get a back port of Commit rL248211 to the openmp 3.7 release branch for the 3.7.1 release? It applies cleanly here over openmp 3.7.0 and shows perfect results...
Jul 24 2015
Also, if we are going to leave the default for CLANG_DEFAULT_OPENMP_RUNTIME set to libgomp, wouldn't it be better to at least modify cfe-3.7.0.src/CMakeLists.txt so that the user could pass -DCLANG_DEFAULT_OPENMP_RUNTIME=libomp to override that default in their own builds of 3.7.0 rather than forcing them to invoke -fopenmp=libomp? Currently we lock them into this unless they manually edit the CMakeLists.txt.
So is the default of -fopenmp=libgomp going to be left in place just for the 3.7.0 release or for all future 3.7.x maintenance releases? Frankly this decision to favor a non-functional OpenMP implementation over own own OpenMP library is baffling if the goal it to get widespread testing of this new feature.
Jul 23 2015
For comparison, the results from the ctest of OpenMP3.1_Validation test suite using the current -fopenmp=libgomp default in 3.7.0 branch are very poor as expected since clang doesn't emit any OpenMP code generation for the libgomp case...
The completeness of the OpenMP 3.1 support in 3.7.0 branch can be seen on x86_64-apple-darwin by using it to run the ctest of OpenMP3.1_Validation test suite from http://web.cs.uh.edu/~hpctools/openmp...
Jul 15 2015
Commit rL242298 still needs to be applied to the openmp 3.7.0 branch as well.
Jul 14 2015
If this misses the branching of 3.7.0, it should be committed to both trunk and 3.7.0 branch.
Jul 13 2015
I can confirm that the ID 29582 version of the proposed patch eliminates the regression on x86_64-apple-darwin14.
The 29443 version of the patch causes the following regression on x86_64-apple-darwin14...
Jul 9 2015
runtime/CMakeLists.txt in 29380 doesn't apply cleanly to current openmp svn...
So are we close to completion with the review process or is there more bikeshedding to be done?
The r241832 and r241833 commits seem to have spoiled the context for applying the proposed cmake overhaul patch.
Jul 7 2015
No problem here applying...
Jul 4 2015
FYI, I have built current openmp trunk with the the third permutation of the cmake overhaul applied as part of an in-tree llvm/clang/compiler-rt/libc++/polly cmake build using a 3-stage bootstrap with stage2/stage3 comparison of binaries on x86_64-apple-darwin13/14/15. The only minor nit I found was that three files should differences between stage2/stage3 due to the timestamps added by
-- stage2/projects/openmp/runtime/src/kmp_i18n_default.inc 2015-07-04 17:04:13.000000000 -0400 +++ stage3/projects/openmp/runtime/src/kmp_i18n_default.inc 2015-07-04 17:28:37.000000000 -0400 @@ -1,5 +1,5 @@ // Do not edit this file! // -// The file was generated from en_US.txt by message-converter.pl on Sat Jul 4 17:04:13 2015. // +// The file was generated from en_US.txt by message-converter.pl on Sat Jul 4 17:28:37 2015. //
Jun 26 2015
Also note that -fopenmp=libomp clang doesn't emit the necessary linkage path to find libomp when llvm/clang/compiler-rt/openmp is built with -DCMAKE_INSTALL_PREFIX set to a buried directory like /opt/local/llvm-3.7.
Jun 25 2015
May 20 2015
I am not having any luck with this proposed patch. Building current llvm/clang/openmp/compiler-rt trunk with it produces a compiler that always defaults to emitting -lgomp for -fopenmp even if cmake is explicitly passed -DENABLE_CLANG_OPENMP=ON.
Feb 19 2015
This change caused a 24% performance regression in the SciMark2's Sparse matmult benchmark on Bloomfield processors and 12% on Harpertown processors with "-O3 -march=native" generating identical assembly in both cases. This issue is filed at http://llvm.org/bugs/show_bug.cgi?id=22589 and appears to be due to the increased register pressure introduced by the newly exposed optimizations causing spills. This issue is processor-specific and the regression is minimal on other processors like Haswell due to their additional registers (at least for this specific test case).