[all-commits] [llvm/llvm-project] 591868: [OpenMP][Tests][NFC] Flagging OMPT tests as XFAIL ...

[Vladimir Inđić via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5918688248fa103c46da3a6ff86e7fab0e63fb45
      https://github.com/llvm/llvm-project/commit/5918688248fa103c46da3a6ff86e7fab0e63fb45
  Author: Joachim Protze <protze at itc.rwth-aachen.de>
  Date:   2021-10-18 (Mon, 18 Oct 2021)

  Changed paths:
    M openmp/runtime/test/ompt/tasks/dependences_mutexinoutset.c
    M openmp/runtime/test/ompt/tasks/taskwait-depend.c
    M openmp/runtime/test/ompt/teams/parallel_team.c
    M openmp/runtime/test/ompt/teams/serial_teams.c
    M openmp/runtime/test/ompt/teams/serialized.c
    M openmp/runtime/test/ompt/teams/team.c

  Log Message:
  -----------
  [OpenMP][Tests][NFC] Flagging OMPT tests as XFAIL for Intel compilers

With Intel 19 compiler the teams tests fail to link while trying to link
liboffload.


  Commit: c93fb143b98ea2035c6fca95241bc5ba40faf97e
      https://github.com/llvm/llvm-project/commit/c93fb143b98ea2035c6fca95241bc5ba40faf97e
  Author: Joachim Protze <protze at itc.rwth-aachen.de>
  Date:   2021-10-18 (Mon, 18 Oct 2021)

  Changed paths:
    M openmp/runtime/test/ompt/synchronization/ordered_dependences.c

  Log Message:
  -----------
  [OpenMP][Tests][NFC] Work around ICC bug
Older intel compilers miss the privatization of nested loop variables for
doacross loops. Declaring the variable in the loop makes the test more
robust.


  Commit: 59a994e8daeef94976841a11bc92ca3a2b6a10b3
      https://github.com/llvm/llvm-project/commit/59a994e8daeef94976841a11bc92ca3a2b6a10b3
  Author: @vladaindjic <vladaindjic at uns.ac.rs>
  Date:   2021-10-18 (Mon, 18 Oct 2021)

  Changed paths:
    M openmp/runtime/src/ompt-specific.cpp
    A openmp/runtime/test/ompt/tasks/explicit_task_thread_num.c

  Log Message:
  -----------
  [OpenMP][OMPT] thread_num determination for programs with explicit tasks

__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


Compare: https://github.com/llvm/llvm-project/compare/3b3509b3cba2...59a994e8daee