[Bug libgomp/103976] New: Very large overhead for if(false) openmp pragmas

[nickpapior at gmail dot com]

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

            Bug ID: 103976
           Summary: Very large overhead for if(false) openmp pragmas
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nickpapior at gmail dot com
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

In OpenMP it may be beneficial to not use OpenMP in a region given that the
calculated workload is very small.

Something like this:

test.c:

#include <stdio.h>

int main(int narg, char args[]) {
  float sum = 0.;
  int i, j;

  for ( i = 1 ; i<=100000000 ; i++) {
#ifdef _OPENMP
#pragma omp parallel for private(j) reduction(+:sum) if(0)
#else
    // Just to have something that resembles the omp-if
    if ( sum >= -1. ) {
#endif
      for (j = 1 ; j<= 10 ; j++)
        sum += 1./j;
#ifndef _OPENMP
    }
#endif
  }

  printf("%15.7e\n", sum);
}


Never mind the faulty results, the idea is the culprit here.

I get the following timings:

gcc -O3 -o a.out test.c  && time ./a.out                                        
./a.out  1.60s user 0.00s system 99% cpu 1.604 total


gcc -O3 -o a.out test.c  -fopenmp && time ./a.out                               
./a.out  9.13s user 4.62s system 99% cpu 13.743 total


Fortran has the same behaviour.
test.F90:

program main

  real :: sum
  integer :: i, j

  sum = 0.

  do i = 1, 100000000
#ifdef _OPENMP
    !$OMP parallel do private(j) reduction(+:sum) if(.false.)
#else
    ! Just to have something that resembles the omp-if
    if ( sum >= -1. ) then
#endif
      do j = 1, 10
        sum = sum + 1./j
      end do
#ifdef _OPENMP
      !$OMP end parallel do
#else
    end if
#endif
  end do

  print *, sum
end program main


The complexity of adding the explicit if's was to emulate an if statement as
inserted in the openmp code. I know that openmp has lots more boiler plate
code, but this still seems awfully slow for me.

This came up in a sparse matrix solution library (MUMPS) which uses the #pragma
omp ... if(workload_huge) to decide on paths.

Let me know if anything else is necessary.