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; }