summaryrefslogtreecommitdiff
path: root/openmp/runtime/src/ompt-specific.cpp
AgeCommit message (Collapse)Author
2025-02-27[OpenMP][OMPT][OMPD] Fix frame flags for OpenMP tool APIs (#114118)Joachim
In several cases the flags entries in ompt_frame_t are not initialized. According to @jdelsign the address provided as reenter and exit address is the canonical frame address (cfa) rather than a "framepointer". This patch makes sure that the flags entry is always initialized and changes the value from ompt_frame_framepointer to ompt_frame_cfa. The assertion in the tests makes sure that the flags are always set, when a tool (callback.h in this case) looks at the value. Fixes #89058
2024-07-16[OpenMP] Use new OMPT state and sync kinds for barrier events (#95602)Hansang Bae
This change makes the runtime use new OMPT state and sync kinds introduced in OpenMP 5.1 in place of the deprecated implicit state and sync kinds. Events from implicit barriers use different enumerators for workshare, parallel, and teams.
2024-06-04[OpenMP][OMPT] Add missing callbacks for asynchronous target tasks (#93472)Joachim
- The first hidden-helper-thread did not trigger thread-begin - The "detaching" from a target-task when waiting for completion missed to call task-switch - Target tasks identified themself as explicit task Co-authored-by: Kaloyan Ignatov <kaloyan.ignatov@rwth-aachen.de>
2023-08-28[OpenMP][OMPT] Fix ompt_get_task_memory implementationJoachim Jenke
Since td_allow_completion_event is a member of the taskdata struct, not all firstprivate/shared variables are stored at the end of the task memory allocation. Simply report the whole allocation instead. Furthermore, the function should always return 0 since in no case there is another block to report. Differential Review: https://reviews.llvm.org/D158080
2023-07-21[OpenMP] [OMPT] [6/8] Added callback support for target data operations, ↵Michael Halkenhaeuser
target submit, and target regions. This patch adds support for invoking target callbacks but does not yet invoke them. A new structure OmptInterface has been added that tracks thread local states including correlation ids. This structure defines methods that will be called from the device independent target library with information related to a target entry point for which a callback is invoked. These methods in turn use the callback functions maintained by OmptDeviceCallbacksTy to invoke the tool supplied callbacks. Depends on D124652 Patch from John Mellor-Crummey <johnmc@rice.edu> With contributions from: Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com> Differential Revision: https://reviews.llvm.org/D127365
2022-11-15[OpenMP] [OMPT] [2/8] Implemented a connector for communication of OMPT ↵Dhruva Chakrabarti
callbacks between libraries. This is part of a set of patches implementing OMPT target callback support and has been split out of the originally submitted https://reviews.llvm.org/D113728. The overall design can be found in https://rice.app.box.com/s/pf3gix2hs4d4o1aatwir1set05xmjljc The purpose of this patch is to provide a way to register tool-provided callbacks into libomp when libomptarget is loaded. Introduced a cmake variable LIBOMPTARGET_OMPT_SUPPORT that can be used to control OMPT target support. It follows host OMPT support, controlled by LIBOMP_HAVE_OMPT_SUPPORT. Added a connector that can be used to communicate between OMPT implementations in libomp and libomptarget or libomptarget and a plugin. Added a global constructor in libomptarget that uses the connector to force registration of tool-provided callbacks in libomp. A pair of init and fini functions are provided to libomp as part of the connect process which will be used to register the tool-provided callbacks in libomptarget. Patch from John Mellor-Crummey <johnmc@rice.edu> (With contributions from Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>) Reviewed By: dreachem, jhuber6 Differential Revision: https://reviews.llvm.org/D123572
2022-11-01Revert "[OpenMP] [OMPT] [2/8] Implemented a connector for communication of ↵Dhruva Chakrabarti
OMPT callbacks between libraries." This reverts commit f94c2679cb1db92ce4103487bf0247eca6e4d722.
2022-10-31[OpenMP] [OMPT] [2/8] Implemented a connector for communication of OMPT ↵Dhruva Chakrabarti
callbacks between libraries. This is part of a set of patches implementing OMPT target callback support and has been split out of the originally submitted https://reviews.llvm.org/D113728. The overall design can be found in https://rice.app.box.com/s/pf3gix2hs4d4o1aatwir1set05xmjljc The purpose of this patch is to provide a way to register tool-provided callbacks into libomp when libomptarget is loaded. Introduced a cmake variable LIBOMPTARGET_OMPT_SUPPORT that can be used to control OMPT target support. It follows host OMPT support, controlled by LIBOMP_HAVE_OMPT_SUPPORT. Added a connector that can be used to communicate between OMPT implementations in libomp and libomptarget or libomptarget and a plugin. Added a global constructor in libomptarget that uses the connector to force registration of tool-provided callbacks in libomp. A pair of init and fini functions are provided to libomp as part of the connect process which will be used to register the tool-provided callbacks in libomptarget. Depends on D123429 Patch from John Mellor-Crummey <johnmc@rice.edu> (With contributions from Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>) Reviewed By: dreachem Differential Revision: https://reviews.llvm.org/D123572
2021-10-25[OpenMP][OMPT] thread_num determination during execution of nested ↵Vladimir Inđić
serialized parallel regions __ompt_get_task_info_internal function is adapted to support thread_num determination during the execution of multiple nested serialized parallel regions enclosed by a regular parallel region. Consider the following program that contains parallel region R1 executed by two threads. Let the worker thread T of region R1 executes serialized parallel regions R2 that encloses another serialized parallel region R3. Note that the thread T is the master thread of both R2 and R3 regions. Assume that __ompt_get_task_info_internal function is called with the argument "ancestor_level == 1" during the execution of region R3. The function should determine the "thread_num" of the thread T inside the team of region R2, whose implicit task is at level 1 inside the hierarchy of active tasks. Since the thread T is the master thread of region R2, one should expected that "thread_num" takes a value 0. After the while loop finishes, the following stands: "lwt != NULL", "prev_lwt == NULL", "prev_team" represents the team information about the innermost serialized parallel region R3. This results in executing the assignment "thread_num = prev_team->t.t_master_tid". Note that "prev_team->t.t_master_tid" was initialized at the moment of R2’s creation and represents the "thread_num" of the thread T inside the region R1 which encloses R2. Since the thread T is the worker thread of the region R1, "the thread_num" takes value 1, which is a contradiction. This patch proposes to use "lwt" instead of "prev_lwt" when determining the "thread_num". If "lwt" exists, the task at the requested level belongs to the serialized parallel region. Since the serialized parallel region is executed by one thread only, the "thread_num" takes value 0. Similarly, assume that __ompt_get_task_info_internal function is called with the argument "ancestor_level == 2" during the execution of region R3. The function should determine the "thread_num" of the thread T inside the team of region R1. Since the thread is the worker inside the region R1, one should expected that "thread_num" takes value 1. After the loop finishes, the following stands: "lwt == NULL", "prev_lwt != NULL", "prev_team" represents the team information about the innermost serialized parallel region R3. This leads to execution of the assignment "thread_num = 0", which causes a contradiction. Ignoring the "prev_lwt" leads to executing the assignment "thread_num = prev_team->t.t_master_tid" instead. From the previous explanation, it is obvious that "thread_num" takes value 1. Note that the "prev_lwt" variable is marked as unnecessary and thus removed. This patch introduces the test case which represents the OpenMP program described earlier in the summary. Differential Revision: https://reviews.llvm.org/D110699
2021-10-18[OpenMP][OMPT] thread_num determination for programs with explicit tasks@vladaindjic
__ompt_get_task_info_internal is now able to determine the right value of the “thread_num” argument during the execution of an explicit task. During the execution of a while loop that iterates over the ancestor tasks hierarchy, the “prev_team” variable was always set to “team” variable at the beginning of each loop iteration. Assume that the program contains a parallel region which encloses an explicit task executed by the worker thread of the region. Also assume that the tool inquires the “thread_num” of a worker thread for the implicit task that corresponds to the region (task at “ancestor_level == 1”) and expects to receive the value of “thread_num > 0”. After the loop finishes, both “team” and “prev_team” variables are equal and point to the team information of the parallel region. The “thread_num” is set to “prev_team->t.t_master_tid”, that is equal to “team->t.t_master_tid”. In this case, “team->t.t_master_tid” is 0, since the master thread of the region is the initial master thread of the program. This leads to a contradiction. To prevent this, “prev_team” variable is set to “team” variable only at the time when the loop that has already encountered the implicit task (“taskdata” variable contains the information about an implicit task) continues iterating over the implicit task’s ancestors, if any. After the mentioned loop finishes, the “prev_team” variable might be equal to NULL. This means that the task at requested “ancestor_level” belongs to the innermost parallel region, so the “thread_num” will be determined by calling the “__kmp_get_tid”. To prove that this patch works, the test case “explicit_task_thread_num.c” is provided. It contains the example of the program explained earlier in the summary. Differential Revision: https://reviews.llvm.org/D110473
2021-08-20[OpenMP][OMPD]Code movement required for OMPDVignesh Balasubramanian
These changes don't come under OMPD guard as it is a movement of existing code to capture parallel behavior correctly. "Runtime Entry Points for OMPD" like "ompd_bp_parallel_begin" and "ompd_bp_parallel_begin" should be placed at the correct execution point for the debugging tool to access proper handles/data. Without the below changes, in certain cases, debugging tool will pick the wrong parallel and task handle. Reviewed By: @hbae Differential Revision: https://reviews.llvm.org/D100366
2021-06-08[OpenMP][OMPD] Implementation of OMPD debugging library - libompd.Vignesh Balasubramanian
This is the first of seven patches that implements OMPD, a debugging interface to support debugging of OpenMP programs. It contains support code required in "openmp/runtime" for OMPD implementation. Reviewed By: @hbae Differential Revision: https://reviews.llvm.org/D100181
2020-12-31[OpenMP] libomp: Handle implicit conversion warningsTerry Wilmarth
This patch partially prepares the runtime source code to be built with -Wconversion, which should trigger warnings if any implicit conversions can possibly change a value. For builds done with icc or gcc, all such warnings are handled in this patch. clang gives a much longer list of warnings, particularly for sign conversions, which the other compilers don't report. The -Wconversion flag is commented into cmake files, but I'm not going to turn it on. If someone thinks it is important, and wants to fix all the clang warnings, they are welcome to. Types of changes made here involve either improving the consistency of types used so that no conversion is needed, or else performing careful explicit conversions, when we're sure a problem won't arise. Patch is a combination of changes by Terry Wilmarth and Johnny Peyton. Differential Revision: https://reviews.llvm.org/D92942
2020-07-31[OpenMP] Use weak attribute in interface only for static libraryJoachim Protze
This is to address the issue reported at: https://bugs.llvm.org/show_bug.cgi?id=46863 Since weak is meaningless for a shared library interface function, this patch disables the attribute, when the OpenMP library is built as shared library. ompt_start_tool is not an interface function, but a internally called function possibly implemented by an OMPT tool. This function needs to be weak if possible to allow overwriting ompt_start_tool with a function implementation built into the application. Differential Revision: https://reviews.llvm.org/D84871
2020-06-19[OpenMP][OMPT] Pass mutexinoutset to the toolJoachim Protze
Adds OMPT support for the mutexinoutset dependency Reviewed by: hbae Differential Revision: https://reviews.llvm.org/D81890
2019-08-03Add OMPT support for teams constructHansang Bae
This change adds OMPT support for events from teams construct. Differential Revision: https://reviews.llvm.org/D64025 llvm-svn: 367746
2019-05-30Add checks before pointer dereferencingHansang Bae
This change adds checks before dereferencing a pointer returned from a function. Differential Revision: https://reviews.llvm.org/D62224 llvm-svn: 362111
2019-05-21[OpenMP] Add implementation to two OMPT API routinesJonathan Peyton
This change adds implementation to ompt_finalize_tool() and ompt_get_task_memory(). Patch by Hansang Bae Differential Revision: https://reviews.llvm.org/D61657 llvm-svn: 361309
2019-05-20[OpenMP][OMPT] Fix locking testcases for 32 bit architecturesJoachim Protze
https://reviews.llvm.org/D58454 did not fix the problem for a typical use case of building LLVM with gcc or icc and then testing with the newly built clang compiler. The compilers do not agree on how to extend a 32-bit pointer to uint64, so make the pointer unsigned first, before adjusting the size. Patch by Joachim Protze Differential Revision: https://reviews.llvm.org/D58506 llvm-svn: 361158
2019-02-28[OpenMP][OMPT] Distinguish different barrier kindsJonathan Peyton
This change makes the runtime decide the intended use of each barrier invocation, for the OMPT synchronization tool callbacks. The OpenMP 5.0 specification defines four possible barrier kinds -- implicit, explicit, implementation, and just normal barrier. Patch by Hansang Bae Differential Revision: https://reviews.llvm.org/D58247 llvm-svn: 355140
2019-01-19Update more file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
2019-01-15[OMPT] Second chunk of final OMPT 5.0 interface updatesJoachim Protze
The omp-tools.h file is generated from the OpenMP spec to ensure that the interface is implemented as specified. The other changes are necessary to update the interface implementation to the final version as published in 5.0. The omp-tools.h header was previously called ompt.h, currently a copy under this name is installed for legacy tools. Patch partially perpared by @sconvent Reviewers: AndreyChurbanov, hbae, Hahnfeld Reviewed By: hbae Tags: #openmp, #ompt Differential Revision: https://reviews.llvm.org/D55579 llvm-svn: 351197
2018-12-18[OMPT] First chunk of final OMPT 5.0 interface updatesJoachim Protze
This patch updates the implementation of the ompt_frame_t, ompt_wait_id_t and ompt_state_t. The final version of the OpenMP 5.0 spec added the "t" for these types. Furthermore the structure for ompt_frame_t changed and allows to specify that the reenter frame belongs to the runtime. Patch partially prepared by Simon Convent Reviewers: hbae llvm-svn: 349458
2018-07-02[OMPT] Provide the right thread_num for ancestor levelsJoachim Protze
The current implementation always provides the thread-num for the current parallel region. This patch fixes the behavior for ancestor levels >0. Differential Revision: https://reviews.llvm.org/D46533 llvm-svn: 336085
2018-05-28[OMPT] Rename ompt_wait_id to omp_wait_idJoachim Protze
Rename ompt_wait_id to omp_wait_id, as defined in the spec. Differential Revision: https://reviews.llvm.org/D46530 llvm-svn: 333368
2018-05-28[OMPT] Rename ompt_frame_t to omp_frame_tJoachim Protze
Rename ompt_frame_t to omp_frame_t, as defined in the spec. Differential Revision: https://reviews.llvm.org/D43568 llvm-svn: 333367
2018-04-12Set the license header for all OMPT filesJoachim Protze
llvm-svn: 329928
2018-02-28[OMPT] Fix ompt_get_task_info() and add tests for itJoachim Protze
The thread_num parameter of ompt_get_task_info() was not being used previously, but need to be set. The print_task_type() function (form the task-types.c testcase) was merged into the print_ids() function (in callback.h). Testing of ompt_get_task_info() was added to the task-types.c testcase. It was not tested extensively previously. Differential Revision: https://reviews.llvm.org/D42472 llvm-svn: 326338
2018-01-17[OMPT] Return appropiate values for ompt runtime entry points for non-OpenMP ↵Joachim Protze
threads When the current thread is not an (initialized) OpenMP thread, the runtime entry points return values that correspond to "not available" or similar Differential Revision: https://reviews.llvm.org/D41167 llvm-svn: 322620
2017-11-07Cleanup version symbol macros and attributes/declspecsJonathan Peyton
1) Get rid of xaliasify, xexpand and xversionify for KMP_EXPAND_NAME and KMP_VERSION_SYMBOL. KMP_VERSION_SYMBOL is a combination of xaliasify and xversionify. 2) Put all attribute and __declspec definitions in kmp_os.h Differential Revision: https://reviews.llvm.org/D39516 llvm-svn: 317636
2017-11-05Rename fields of ompt_frame_tJoachim Protze
This is part of the renaming of data types from OpenMP TR4 to TR6 Patch by Simon Convent Differential Revision: https://reviews.llvm.org/D39326 llvm-svn: 317435
2017-11-03Revert "Rename fields of ompt_frame_t"Jonas Hahnfeld
This reverts commit r317338 which discarded some recent commits. llvm-svn: 317347
2017-11-03Revert "Updating implementation of OMPT as specified in OpenMP 5.0 Preview 2 ↵Jonas Hahnfeld
(TR6)" This reverts commit r317339 which discarded some recent commits. llvm-svn: 317346
2017-11-03Updating implementation of OMPT as specified in OpenMP 5.0 Preview 2 (TR6)Joachim Protze
The TR6 document is expected to be publically released around November 15. This patch does not implement OMPT for libomptarget. Patch by Simon Convent and Joachim Protze Differential Revision: https://reviews.llvm.org/D39182 llvm-svn: 317339
2017-11-03Rename fields of ompt_frame_tJoachim Protze
This is part of the renaming of data types from OpenMP TR4 to TR6 Patch by Simon Convent Differential Revision: https://reviews.llvm.org/D39326 llvm-svn: 317338
2017-11-01Update implementation of OMPT to the specification OpenMP 5.0 Preview 1 (TR4).Joachim Protze
The code is tested to work with latest clang, GNU and Intel compiler. The implementation is optimized for low overhead when no tool is attached shifting the cost to execution with tool attached. This patch does not implement OMPT for libomptarget. Patch by Simon Convent and Joachim Protze Differential Revision: https://reviews.llvm.org/D38185 llvm-svn: 317085
2017-05-12Clang-format and whitespace cleanup of source codeJonathan Peyton
This patch contains the clang-format and cleanup of the entire code base. Some of clang-formats changes made the code look worse in places. A best effort was made to resolve the bulk of these problems, but many remain. Most of the problems were mangling line-breaks and tabbing of comments. Patch by Terry Wilmarth Differential Revision: https://reviews.llvm.org/D32659 llvm-svn: 302929
2016-12-14Change source files from .c to .cppJonathan Peyton
Patch by Hansang Bae Differential Revision: https://reviews.llvm.org/D26688 llvm-svn: 289732