libflangrti.so should depend on libompstub.so instead of libomp.so

[pawosm-arm]

This commit drops unfortunate dependency of libflangrti.so
on libomp.so.

For non-OpenMP programs (built without -fopenmp flag) frontend
driver instructs the linker to link against libompstub.so library,
which exports stubs for all OpenMP runtime library symbols. This is
because Flang runtime library contains calls to those symbols
(for OpenMP programs, final binary is linked against libomp.so
instead).

Apart form above, all of the Fortran programs are linked against
libflang.so and libflangrti.so. Unfortunately, before this change
libflangrti.so was depending on full blown OpenMP runtime library
(libomp.so).

This commit creates two sets of Flang runtime shared objects with
following chains of dependencies:

1. libflang.so -> libflangrti.so -> libompstub.so
2. libflang-omp.so -> libflangrti-omp.so -> libomp.so

Note that in order for this change to be in effect, relevant commit
must be also applied on the clang repository.

[flang-cavium]

I have a question of a much more generic nature: why is a dependency on libompstub.so required for non-OpenMP programs?

Normally, non-OpenMP programs and/or libraries should have no dependencies on any OpenMP interfaces. Meaning, without passing -fopenmp on compile-line, there should be no OpenMP interfaces imported into the resulting binary.

From looking at the libflangrti.so code, OpenMP interfaces are being used to enforce serialized access to local shared resources (i.e. static objects).

All of this can be accomplished in a more efficient manner simply by using POSIX threads serialization interfaces. And it would remove any dependencies on OpenMP, and the need to import interfaces from libompstub.so, for non-OpenMP programs.

I am concerned that this insertion of OpenMP interfaces into non-OpenMP programs runs afoul of the SPEC rules for SPEC-rate. The SPEC rules for SPEC-rate explicitly forbid OpenMP:

https://www.spec.org/cpu2017/Docs/runrules.html#rule_2.2

# 2.2.6. Compiler parallelization is allowed for SPECspeed, not allowed for SPECrate

Compiler flags that enable multi-threaded execution, whether by explicit OpenMP directive, or by automatic parallelization, are allowed only when building the SPECspeed benchmarks. For SPECrate, it is forbidden to use compiler parallelization (both explicit OpenMP and auto-parallelization are forbidden).

For example, the GCC flags -fopenmp and -floop-parallelize-all are allowed when building the SPECspeed Integer benchmarks, such as 657.xz_s; the same switches are forbidden when building the SPECrate Integer benchmarks, such as 557.xz_r.

Note: this rule does not forbid the use of SIMD instructions (Single Instruction, Multiple Data). For example, the GCC flag -mfpmath=sse is allowed in both SPECspeed and SPECrate.

[pawosm-arm]

This fix is insufficient. We are handling it different, more radical way