This is an archive of the discontinued LLVM Phabricator instance.

[OpenMP] Add support for ompt_callback_dispatch
ClosedPublic

Authored by hbae on Mar 20 2022, 2:49 PM.

Details

Summary

This change adds support for ompt_callback_dispatch with the new
dispatch chunk type introduced in 5.2. Definitions of the new
ompt_work_loop types were also added (but not used now).

Diff Detail

Event Timeline

hbae created this revision.Mar 20 2022, 2:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 20 2022, 2:49 PM
hbae requested review of this revision.Mar 20 2022, 2:49 PM
AndreyChurbanov added inline comments.Apr 4 2022, 8:45 AM
openmp/runtime/test/ompt/teams/distribute_dispatch.c
3

Missing

// REQUIRES: ompt
openmp/runtime/test/ompt/worksharing/for/loop_dispatch.c
3

Missing

// REQUIRES: ompt
openmp/runtime/test/ompt/worksharing/sections_dispatch.c
3

Missing

// REQUIRES: ompt
hbae updated this revision to Diff 420311.Apr 4 2022, 2:34 PM

Added missing REQUIRES line.

This revision is now accepted and ready to land.Apr 5 2022, 2:19 AM
protze.joachim accepted this revision.Apr 6 2022, 1:51 AM

Thanks for working on this!

Just one comment inline.

openmp/runtime/test/ompt/callback.h
792–804

Can you probably add a TODO, that we should add a new attribute here: ", schedule=%s" ... ompt_schedule_values[wstype]?

This can be added with the specialization change of ompt_work_loop.

This revision was automatically updated to reflect the committed changes.
hbae added inline comments.Apr 6 2022, 6:03 AM
openmp/runtime/test/ompt/callback.h
792–804

Pushed my change after adding the suggested comments.

tianshilei1992 added inline comments.
openmp/runtime/src/ompt-internal.h
60

This LoC creates tens of compilation warning. Please fix it.

In file included from /home/shiltian/Documents/vscode/llvm-project/openmp/runtime/src/kmp_affinity.cpp:13:
In file included from /home/shiltian/Documents/vscode/llvm-project/openmp/runtime/src/kmp.h:139:
/home/shiltian/Documents/vscode/llvm-project/openmp/runtime/src/ompt-internal.h:55:15: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef struct {
              ^
               ompt_task_info_t
/home/shiltian/Documents/vscode/llvm-project/openmp/runtime/src/ompt-internal.h:60:42: note: type is not C-compatible due to this default member initializer
  ompt_dispatch_chunk_t dispatch_chunk = {0, 0};
                                         ^~~~~~
/home/shiltian/Documents/vscode/llvm-project/openmp/runtime/src/ompt-internal.h:61:3: note: type is given name 'ompt_task_info_t' for linkage purposes by this typedef declaration
} ompt_task_info_t;
  ^
1 warning generated.
aganea added a subscriber: aganea.Apr 8 2022, 8:24 AM

Hello! It seems the loop_dispatch.c test is occasionally causing errors on one of the builders: https://lab.llvm.org/buildbot/#/builders/84/builds/22238/steps/6/logs/FAIL__libomp__loop_dispatch_c (also see the builder's history)
Anyone would have a chance to look at it please? Thanks in advance!

hbae added a comment.Apr 8 2022, 9:35 AM

Is it possible for me to access the output of the failed test shown in the log?
/b/1/openmp-clang-x86_64-linux-debian/llvm.build/projects/openmp/runtime/test/ompt/worksharing/for/Output/loop_dispatch.c.tmp.out

ychen added a subscriber: ychen.Apr 28 2022, 1:48 PM

Hello! It seems the loop_dispatch.c test is occasionally causing errors on one of the builders: https://lab.llvm.org/buildbot/#/builders/84/builds/22238/steps/6/logs/FAIL__libomp__loop_dispatch_c (also see the builder's history)
Anyone would have a chance to look at it please? Thanks in advance!

yep, I saw this too. https://lab.llvm.org/buildbot/#/builders/84/builds/23076

openmp/runtime/test/ompt/worksharing/for/loop_dispatch.c
11–29

@hbae because of dynamic schedule it is possible that some thread gets no iteration. I'm not sure how the runtime behaves in such case.

I think we should replace the delay by signal-wait code similar to the tasking tests to make sure that all threads get at least one iteration.

Although nthreads should be 4 most of the time, with limited resources, the runtime might use less threads. In that case we should not deadlock - the test will fail nevertheless.