https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103976
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Even with if (0) it has to do that. if (0) doesn't say act as if the construct
isn't there, it says that it should act as if num_threads is forced to 1. It
still creates an inactive parallel region and needs to do various actions to
the ICVs etc. that can be observed through various OpenMP APIs.
What we perhaps could do if we see if (0) or num_threads (1) is not use atomics
for the reductions if there aren't task reductions, as with a guaranteed single
thread they aren't needed. But it would be an optimization for something very
rare, when if is used, it typically is not a compile time value and when we
don't know if it is true or false, we can't optimize away those atomics.
Note, this is unlike the task directive which with mergeable directive can (but
doesn't have to and GCC doesn't implement that right now) avoid the data
environment changes in certain conditions, so
#pragma omp task mergeable other_clauses
body;
could be implemented either something like:
GOMP_task (outlined_body, ...);
as GCC does now, but also as say:
if (GOMP_taskWHATEVER (outlined_body, ... GOMP_MERGEABLE, ...)
body;
where the library would determine if it is an undeferred or included task (and
does any needed waiting for depend clauses etc.), but instead of creating a new
task in that case it would signal to the caller that the outlined_body won't be
called and that it should invoke body instead. But probably only if there
aren't any depend clauses, otherwise variables changed during the waiting for
other task could get different values from what they contained originally.
