Changed omp_get_max_threads() implementation to more closely match spec description.
authorEthan Stewart <ethan.stewart@amd.com>
Wed, 12 Feb 2020 23:29:10 +0000 (23:29 +0000)
committerJonChesterfield <jonathanchesterfield@gmail.com>
Wed, 12 Feb 2020 23:29:34 +0000 (23:29 +0000)
commit190a11148b756e0b650ad9c5b6cf5314e9afdd0a
treee2a3525881fdd80f42d2df8f3bbf8ce19f38dd76
parentc2ce9ea4e372ee31271da44c727dc598e12261a5
Changed omp_get_max_threads() implementation to more closely match spec description.

Summary: The 5.0 spec states, "The omp_get_max_threads routine returns an upper bound on the number of threads that could be used to form a new team if a parallel construct without a num_threads clause were encountered after execution returns from this routine." The attached test shows Max Threads: 96, Num Threads: 128 without the proposed change. The number of threads should not exceed the (max) nthreads ICV, hence we should return the higher SPMD thread number even when omp_get_max_threads() is called in a generic kernel. This change does fail the api test, max_threads.c, because now it would return 64 instead of 32.

Reviewers: jdoerfert, ABataev, grokos, JonChesterfield

Reviewed By: jdoerfert

Subscribers: openmp-commits

Tags: #openmp

Differential Revision: https://reviews.llvm.org/D74092
openmp/libomptarget/deviceRTLs/common/src/omptarget.cu
openmp/libomptarget/deviceRTLs/nvptx/test/api/get_max_threads.c [new file with mode: 0644]
openmp/libomptarget/deviceRTLs/nvptx/test/api/max_threads.c