Page MenuHomePhabricator

[OpenMP][FIX] Do not signal SPMD-mode but then keep generic-mode
ClosedPublic

Authored by jdoerfert on Oct 31 2021, 12:52 PM.

Details

Summary

If we assume SPMD-mode during the fixpoint iteration we have to execute
the kernel in SPMD-mode. If we change our mind during manifest there is
the chance of a mismatch between the simplification, e.g., of
__kmpc_is_spmd_exec_mode calls, and the execution mode. This problem
was introduced in D109438.

This patch is compromise to resolve the problem purely in OpenMP-opt
while trying to keep the benefits of D109438 around. This might not
always work, see get_hardware_num_threads_in_block_fold but it often
does. At the same time we do keep value specialization and execution
mode in sync.

Proper solutions to this problem should be considered. I believe a new
execution mode is the easiest way forward (Singleton-SPMD).
Alternatively, SPMD-mode execution can be used with a way to provide a
new thread_limit (here 1) to the runtime. This is more general and could
be useful if we see num_threads clauses or workshared loops with small
trip counts in the kernel. In either proposal we need to disable the
guarding for the kernel (which was the motivation for D109438).

Diff Detail

Event Timeline

jdoerfert created this revision.Oct 31 2021, 12:52 PM
jdoerfert requested review of this revision.Oct 31 2021, 12:52 PM
Herald added a reviewer: baziotis. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
jhuber6 accepted this revision.Nov 1 2021, 6:55 AM

LGTM.

This revision is now accepted and ready to land.Nov 1 2021, 6:55 AM
This revision was landed with ongoing or failed builds.Nov 2 2021, 9:23 PM
This revision was automatically updated to reflect the committed changes.