- Nov 28, 2016
-
-
Jonathan Peyton authored
Patch by Victor Campos Differential Revision: https://reviews.llvm.org/D27172 llvm-svn: 288056
-
- Nov 21, 2016
-
-
Jonathan Peyton authored
llvm-svn: 287552
-
- Oct 27, 2016
-
-
Andrey Churbanov authored
Differential Revision: http://reviews.llvm.org/D25504 Patch by Alex Duran. llvm-svn: 285283
-
- Oct 26, 2016
-
-
Jonathan Peyton authored
Patch by Victor Campos Differential Revision: https://reviews.llvm.org/D25972 llvm-svn: 285244
-
- Aug 08, 2016
-
-
Jonas Hahnfeld authored
Consider the following code: int dep; #pragma omp target nowait depend(out: dep) { sleep(1); } #pragma omp task depend(in: dep) { printf("Task with dependency\n"); } printf("Doing some work...\n"); In its current state the runtime will block on the second task and not continue execution. Differential Revision: https://reviews.llvm.org/D23116 llvm-svn: 277992
-
- Aug 04, 2016
-
-
Jonas Hahnfeld authored
node->dn.task is only filled after the dependencies are already processed. This currently leads to unhelpful output from KA_TRACE or even a crash if one enables KMP_SUPPORT_GRAPH_OUTPUT. llvm-svn: 277717
-
- Jun 16, 2016
-
-
Jonathan Peyton authored
With single thread using __kmpc_omp_wait_deps segfaults in OpenMP runtime. Offloading with depend also encounters this problem when we generate kmpc_omp_wait_deps instead of kmpc_omp_task_with_deps. Patch by Alex Duran Differential Revision: http://reviews.llvm.org/D21384 llvm-svn: 272949
-
- Jun 14, 2016
-
-
Jonathan Peyton authored
OpenMP 4.1 is now OpenMP 4.5. Any mention of 41 or 4.1 is replaced with 45 or 4.5. Also, if the CMake option LIBOMP_OMP_VERSION is 41, CMake warns that 41 is deprecated and to use 45 instead. llvm-svn: 272687
-
- May 20, 2016
-
-
Jonathan Peyton authored
This patch doesn't affect D19878's context. So D19878 still cleanly applies. llvm-svn: 270252
-
- Jan 29, 2016
-
-
Jonathan Peyton authored
In: http://lists.llvm.org/pipermail/openmp-dev/2015-August/000858.html, a performance issue was found with libomp's task dependencies. The task dependencies hash table has an issue with collisions. The current table size is a power of two. This combined with the current hash function causes a large number of collisions to occurr. Also, the current size (64) is too small for larger applications so the table size is increased. This patch creates a two level hash table approach for task dependencies. The implicit task is considered the "master" or "top-level" task which has a large static sized hash table (997), and nested tasks will have smaller hash tables (97). Prime numbers were chosen to help reduce collisions. Differential Revision: http://reviews.llvm.org/D16640 llvm-svn: 259113
-
- Jan 28, 2016
-
-
Jonas Hahnfeld authored
The attached patch adds support for ompt_event_task_dependences and ompt_event_task_dependence_pair events from the OMPT specification [1]. These events only apply to OpenMP 4.0 and 4.1 (aka 4.5) because task dependencies were introduced in 4.0. With respect to the changes: ompt_event_task_dependences According to the specification, this event is raised after the task has been created, thefore this event needs to be raised after ompt_event_task_begin (in __kmp_task_start). However, the dependencies are known at __kmpc_omp_task_with_deps which occurs before __kmp_task_start. My modifications extend the ompt_task_info_t struct in order to store the dependencies of the task when _kmpc_omp_task_with_deps occurs and then they are emitted in __kmp_task_start just after raising the ompt_event_task_begin. The deps field is allocated and valid until the event is raised and it is freed and set to null afterwards. ompt_event_task_dependence_pair The processing of the dependences (i.e. checking whenever a dependence is already satisfied) is done within __kmp_process_deps. That function checks every dependence and calls the __kmp_track_dependence routine which gives some support for graphical output. I used that routine to emit the dependence pair but I also needed to know the sink_task. Despite the fact that the code within KMP_SUPPORT_GRAPH_OUTPUT refers to task_sink it may be null because sink->dn.task (there's a comment regarding this) and in fact it does not point to a proper pointer value because the value is set in node->dn.task = task; after the __kmp_process_deps calls in __kmp_check_deps. I have extended the __kmp_process_deps and __kmp_track_dependence parameter list to receive the sink_task. [1] https://github.com/OpenMPToolsInterface/OMPT-Technical-Report/blob/target/ompt-tr.pdf Patch by Harald Servat Differential Revision: http://reviews.llvm.org/D14746 llvm-svn: 259038
-
- Nov 16, 2015
-
-
Jonathan Peyton authored
llvm-svn: 253265
-
- Aug 26, 2015
-
-
Jonathan Peyton authored
These variables are only used in the TRACE macros and so don't need to be defined unless compiling in debug mode. llvm-svn: 246067
-
- Jun 08, 2015
-
-
Jonathan Peyton authored
Some variables are convenient to keep around even if they aren't really used in a release build. This is often seen in DEBUG guarded code where the variable is only used in a DEBUG build. Patch by Jack Howarth llvm-svn: 239326
-
- May 07, 2015
-
-
Andrey Churbanov authored
llvm-svn: 236753
-
- Jan 27, 2015
-
-
Andrey Churbanov authored
llvm-svn: 227207
-
- Oct 07, 2014
-
-
Jim Cownie authored
understand that this is not friendly, and are working to change our internal code-development to make it easier to make development features available more frequently and in finer (more functional) chunks. Unfortunately we haven't got that in place yet, and unpicking this into multiple separate check-ins would be non-trivial, so please bear with me on this one. We should be better in the future. Apologies over, what do we have here? GGC 4.9 compatibility -------------------- * We have implemented the new entrypoints used by code compiled by GCC 4.9 to implement the same functionality in gcc 4.8. Therefore code compiled with gcc 4.9 that used to work will continue to do so. However, there are some other new entrypoints (associated with task cancellation) which are not implemented. Therefore user code compiled by gcc 4.9 that uses these new features will not link against the LLVM runtime. (It remains unclear how to handle those entrypoints, since the GCC interface has potentially unpleasant performance implications for join barriers even when cancellation is not used) --- new parallel entry points --- new entry points that aren't OpenMP 4.0 related These are implemented fully :- GOMP_parallel_loop_dynamic() GOMP_parallel_loop_guided() GOMP_parallel_loop_runtime() GOMP_parallel_loop_static() GOMP_parallel_sections() GOMP_parallel() --- cancellation entry points --- Currently, these only give a runtime error if OMP_CANCELLATION is true because our plain barriers don't check for cancellation while waiting GOMP_barrier_cancel() GOMP_cancel() GOMP_cancellation_point() GOMP_loop_end_cancel() GOMP_sections_end_cancel() --- taskgroup entry points --- These are implemented fully. GOMP_taskgroup_start() GOMP_taskgroup_end() --- target entry points --- These are empty (as they are in libgomp) GOMP_target() GOMP_target_data() GOMP_target_end_data() GOMP_target_update() GOMP_teams() Improvements in Barriers and Fork/Join -------------------------------------- * Barrier and fork/join code is now in its own file (which makes it easier to understand and modify). * Wait/release code is now templated and in its own file; suspend/resume code is also templated * There's a new, hierarchical, barrier, which exploits the cache-hierarchy of the Intel(r) Xeon Phi(tm) coprocessor to improve fork/join and barrier performance. ***BEWARE*** the new source files have *not* been added to the legacy Cmake build system. If you want to use that fixes wil be required. Statistics Collection Code -------------------------- * New code has been added to collect application statistics (if this is enabled at library compile time; by default it is not). The statistics code itself is generally useful, the lightweight timing code uses the X86 rdtsc instruction, so will require changes for other architectures. The intent of this code is not for users to tune their codes but rather 1) For timing code-paths inside the runtime 2) For gathering general properties of OpenMP codes to focus attention on which OpenMP features are most used. Nested Hot Teams ---------------- * The runtime now maintains more state to reduce the overhead of creating and destroying inner parallel teams. This improves the performance of code that repeatedly uses nested parallelism with the same resource allocation. Set the new KMP_HOT_TEAMS_MAX_LEVEL envirable to a depth to enable this (and, of course, OMP_NESTED=true to enable nested parallelism at all). Improved Intel(r) VTune(Tm) Amplifier support --------------------------------------------- * The runtime provides additional information to Vtune via the itt_notify interface to allow it to display better OpenMP specific analyses of load-imbalance. Support for OpenMP Composite Statements --------------------------------------- * Implement new entrypoints required by some of the OpenMP 4.1 composite statements. Improved ifdefs --------------- * More separation of concepts ("Does this platform do X?") from platforms ("Are we compiling for platform Y?"), which should simplify future porting. ScaleMP* contribution --------------------- Stack padding to improve the performance in their environment where cross-node coherency is managed at the page level. Redesign of wait and release code --------------------------------- The code is simplified and performance improved. Bug Fixes --------- *Fixes for Windows multiple processor groups. *Fix Fortran module build on Linux: offload attribute added. *Fix entry names for distribute-parallel-loop construct to be consistent with the compiler codegen. *Fix an inconsistent error message for KMP_PLACE_THREADS environment variable. llvm-svn: 219214
-
- Sep 27, 2013
-
-
Jim Cownie authored
llvm-svn: 191506
-