Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2016-06-14T17:57:47+00:00 2016-06-14T17:57:47+00:00 Jonathan Peyton jonathan.l.peyton@intel.com 2016-06-14T17:57:47+00:00 urn:sha1:df6818bea4f513a5c7adcd203905163d4052cb1b 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 2016-05-31T19:01:15+00:00 Jonathan Peyton jonathan.l.peyton@intel.com 2016-05-31T19:01:15+00:00 urn:sha1:067325f935e3d43d4b2b6e2dbe122ba6daf35359 The problem is the lack of dispatch buffers when thousands of loops with nowait, about 10 iterations each, are executed by hundreds of threads. We only have built-in 7 dispatch buffers, but there is a need in dozens or hundreds of buffers. The problem can be fixed by setting KMP_MAX_DISP_BUF to bigger value. In order to give users same possibility I changed build-time control into run-time one, adding API just in case. This change adds an environment variable KMP_DISP_NUM_BUFFERS and a new API function kmp_set_disp_num_buffers(int num_buffers). The KMP_DISP_NUM_BUFFERS envirable works only before serial initialization, because during the serial initialization we already allocate buffers for the hot team, so it is too late to change the number of buffers later (or we need to reallocate buffers for all teams which sounds too complicated). The kmp_set_defaults() routine does not work for this envirable, because it calls serial initialization before reading the parameter string. So a new routine, kmp_set_disp_num_buffers(), is created so that it can set our internal global variable before the library initialization. If both the envirable and API used the envirable wins. Differential Revision: http://reviews.llvm.org/D20697 llvm-svn: 271318 2016-05-23T16:24:39+00:00 Jonathan Peyton jonathan.l.peyton@intel.com 2016-05-23T16:24:39+00:00 urn:sha1:b2b6d4e2e1d881e3e48bb2b60c249a43634ae587 llvm-svn: 270447 2016-05-20T19:03:38+00:00 Jonathan Peyton jonathan.l.peyton@intel.com 2016-05-20T19:03:38+00:00 urn:sha1:611184919f87030643f96832a8c875f489b68ec9 This patch doesn't affect D19878's context. So D19878 still cleanly applies. llvm-svn: 270252 2016-05-12T22:00:37+00:00 Jonathan Peyton jonathan.l.peyton@intel.com 2016-05-12T22:00:37+00:00 urn:sha1:f83ae31cafc8869a563070b44390646f890a6d26 This change adds a new entry point, kmp_aligned_malloc(size_t size, size_t alignment), an entry point corresponding to kmp_malloc() but with the capability to return aligned memory as well. Other allocator routines have been adjusted so that kmp_free() can be used for freeing memory blocks allocated by any kmp_*alloc() routine, including the new kmp_aligned_malloc() routine. Differential Revision: http://reviews.llvm.org/D19814 llvm-svn: 269365 2016-04-12T20:37:18+00:00 Jonathan Peyton jonathan.l.peyton@intel.com 2016-04-12T20:37:18+00:00 urn:sha1:2e379fc76733b7dfded8c0487c44073c8e484fa2 All these routines are implemented in the offload library. llvm-svn: 266120 2016-02-25T18:49:52+00:00 Jonathan Peyton jonathan.l.peyton@intel.com 2016-02-25T18:49:52+00:00 urn:sha1:2f7c077b5adc9598dd9b70a28602ae678a8f8f7b This change introduces the new OpenMP 4.5 affinity api surrounding OpenMP Places. There are six new entry points: Typically called in serial region: * omp_get_num_places - returns the number of places available to the execution environment in the place list. * omp_get_place_num_procs - returns the number of processors available to the execution environment in the specified place. * omp_get_place_proc_ids - returns the numerical identifiers of the processors available to the execution environment in the specified place. Typically called inside parallel region: * omp_get_place_num - returns the place number of the place to which the encountering thread is bound. * omp_get_partition_num_places - returns the number of places in the place partition of the innermost implicit task. * omp_get_partition_place_nums - returns the list of place numbers corresponding to the places in the place-var ICV of the innermost implicit task. Differential Revision: http://reviews.llvm.org/D17417 llvm-svn: 261915 2016-02-25T18:04:09+00:00 Jonathan Peyton jonathan.l.peyton@intel.com 2016-02-25T18:04:09+00:00 urn:sha1:2851072d69af205fd8d2ef438db7e4848afb1592 The maximum task priority value is read from envirable: OMP_MAX_TASK_PRIORITY. But as of now, nothing is done with it. We just handle the environment variable and add the new api: omp_get_max_task_priority() which returns that value or zero if it is not set. Differential Revision: http://reviews.llvm.org/D17411 llvm-svn: 261908 2016-01-28T10:39:52+00:00 Jonas Hahnfeld Hahnfeld@itc.rwth-aachen.de 2016-01-28T10:39:52+00:00 urn:sha1:39b686248264e7700c48d54a6e01c02563befa68 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 2016-01-28T07:14:44+00:00 Jonas Hahnfeld Hahnfeld@itc.rwth-aachen.de 2016-01-28T07:14:44+00:00 urn:sha1:bba248c36833b8a3ec8d245b14f72fa9b8a9c405 Current clang trunk reports _OPENMP to be 201307 = OpenMP 4.0. It doesn't recognize '#pragma omp declare target' though (patch still pending) and therefore fails compilation. Differential Revision: http://reviews.llvm.org/D16631 llvm-svn: 259026