[Bug middle-end/68706] New: OpenMP reduction lowering too eager to use GOMP_atomic_start/end

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68706

            Bug ID: 68706
           Summary: OpenMP reduction lowering too eager to use
                    GOMP_atomic_start/end
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: openmp
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amonakov at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

When multiple OpenMP reductions are specified, GCC gives up using atomic
updates and wraps reductions with GOMP_atomic_start () / GOMP_atomic_end (). 
omp-low.c:lower_reduction_clauses() has:

5492   /* First see if there is exactly one reduction clause.  Use OMP_ATOMIC
5493      update in that case, otherwise use a lock.  */

But giving up already on two reductions, if the machine can handle them
natively, is way too early.  It's as if the implementation expects that most of
the time reductions cannot be lowered to atomic insns or cas-retry loops, and
would require GOMP_atomic_start/end wrapping anyway.

Is that necessary?  Can this be dropped at least in target regions?

Reductions microbenchmark:

#include <omp.h>
int main()
{
  int s=0, r=0;
  #pragma omp parallel
  for (int i = 0; i < 1000000; i++)
  #pragma omp for reduction (+:s,r) nowait
    for (int j = 0; j < omp_get_num_threads(); j++)
      s++, r++;
  return s+r;
}