[all-commits] [llvm/llvm-project] d29a7d: [OpenMP][Tools][NFC] Pass intel license ENV to lit

Mon Oct 25 09:23:26 PDT 2021

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

  Changed paths:
    M openmp/tools/multiplex/tests/lit.cfg

  Log Message:
  -----------
  [OpenMP][Tools][NFC] Pass intel license ENV to lit

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

  Changed paths:
    M openmp/runtime/test/lit.cfg
    M openmp/runtime/test/ompt/callback.h
    M openmp/runtime/test/ompt/synchronization/ordered_dependences.c
    M openmp/runtime/test/worksharing/for/omp_par_in_loop.c

  Log Message:
  -----------
  [OpenMP][Tools][NFC] Fix C99-style declaration of iteration variables

Where possible change to declare the variable before the loop.
Where not possible, specifically request -std=c99 (could be limited to
specific compilers like icc).

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

  Changed paths:
    M openmp/runtime/test/worksharing/for/omp_for_bigbounds.c

  Log Message:
  -----------
  [OpenMP][Tests][NFC] Replace atomic increment by reduction

Also mark the test as unsupported by intel-21, because the test does
not terminate

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

  Changed paths:
    M openmp/runtime/test/api/omp_get_num_devices.c
    M openmp/runtime/test/api/omp_pause_resource.c
    M openmp/runtime/test/critical/omp_critical_with_hint.c
    M openmp/runtime/test/teams/kmp_num_teams.c

  Log Message:
  -----------
  [OpenMP][Tests][NFC] Mark tests trying to link COI as unsupported

For some tests with target-related functionality icc 18/19 tries to link
libioffload_target.so.5, which fails for missing COI symbols.

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

  Changed paths:
    M openmp/runtime/test/tasking/detach_nested_task.c

  Log Message:
  -----------
  [OpenMP][Tests][NFC] Actually check for test outcome

The CHECK: line in the test had no effect, because the test does not
pipe to FileCheck. Since the test only checks for a single value,
encode the result in the return value of the test.

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

  Changed paths:
    M openmp/runtime/test/api/omp_get_wtime.c

  Log Message:
  -----------
  [OpenMP][Tests] Test omp_get_wtime for invariants

As discussed in D108488, testing for invariants of omp_get_wtime would be more
reliable than testing for duration of sleep, as return from sleep might be
delayed due to system load.

Alternatively/in addition, we could compare the time measured by omp_get_wtime
 to time measured with C++11 chrono (for portability?).

Differential Revision: https://reviews.llvm.org/D112458

  Commit: f2410bfb1c49b6610a8a96dfb22b20d5b478ea17
      https://github.com/llvm/llvm-project/commit/f2410bfb1c49b6610a8a96dfb22b20d5b478ea17
  Author: Vladimir Inđić <vladaindjic at uns.ac.rs>
  Date:   2021-10-25 (Mon, 25 Oct 2021)

  Changed paths:
    M openmp/runtime/src/kmp_csupport.cpp
    A openmp/runtime/test/ompt/parallel/nested_serialized_task_frames.c
    A openmp/runtime/test/ompt/parallel/region_in_expl_task_task_frames.c

  Log Message:
  -----------
  [OpenMP][OMPT][clang] task frame support fixed in __kmpc_fork_call

__kmp_fork_call sets the enter_frame of the active task (th_curren_task)
before new parallel region begins. After the region is finished, the
enter_frame is cleared.

The old implementation of __kmpc_fork_call didn’t clear the enter_frame of
active task.

Also, the way of initializing the enter_frame of the active task was wrong.
Consider the following two OpenMP programs.

The first program: Let R1 be the serialized parallel region that encloses
another serialized parallel region R2. Assume that thread that executes R2 is
going to create a new serialized parallel region R3 by executing
__kmpc_fork_call. This thread is responsible to set enter_frame of R2's
implicit task. Note that the information about R2's implicit task is present
inside master_th->th.th_current_task at this moment, while lwt represents the
information about R1's implicit task. The old implementation uses lwt and
resets enter_frame of R1's implicit task instead of R2's implicit task. The
new implementation uses master_th->th.th_current_task instead.

The second program: Consider the OpenMP program that contains parallel region
R1 which encloses an explicit task T. Assume that thread should create another
parallel region R2 during the execution of the T. The __kmpc_fork_call is
responsible to create R2 and set enter frame of T whose information is present
inside the master_th->th.th_current_task.
Old implementation tries to set the frame of
parent_team->t.t_implicit_task_taskdata[tid] which corresponds to the implicit
task of the R1, instead of T.

Differential Revision: https://reviews.llvm.org/D112419

  Commit: f41d08540be21f852b7ee6293953f66f5a1123b6
      https://github.com/llvm/llvm-project/commit/f41d08540be21f852b7ee6293953f66f5a1123b6
  Author: Vladimir Inđić <vladaindjic at uns.ac.rs>
  Date:   2021-10-25 (Mon, 25 Oct 2021)

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

  Log Message:
  -----------
  [OpenMP][OMPT] thread_num determination during execution of nested 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

Compare: https://github.com/llvm/llvm-project/compare/974c2f5e2211...f41d08540be2