Removing spec versioning from the OpenMP runtime

Hello,

We’re considering removing all of the spec versioning in the runtime. This is the set of spec-version-numbered #ifdefs throughout the runtime (such as OMP_40_ENABLED, OMP_45_ENABLED, OMP_50_ENABLED, etc.) that make it possible to build earlier versions of the runtime that are compliant with a certain spec version, via LIBOMP_OMP_VERSION.

The main reasons to remove this:

  1. No one seems to be using the spec-version builds.

  2. The #ifdefs are often not well-maintained or correctly added.

  3. The #ifdefs add clutter to the source.

We’d like to get some feedback on removing this. If we’re generally in agreement that it should be removed, we’ll start work on the cleanup.

Thanks!

Terry

Terry L. Wilmarth
terry.l.wilmarth@intel.com 512-362-0530
Intel/Threading Runtimes

My opinion should be given very low weight but this sounds like a great plan.

Jeff

Hi Terry,

I'm in favor as suggested in https://reviews.llvm.org/D55496.
To add another argument that was raised in that review: Currently the tests need to be versioned as well, which is another maintenance burden.

Cheers,
Jonas

Since there are no objections to this, we'll start on it soon.
Thanks for the feedback!

Hi all,

sorry for necromancing on this thread :smiley:

I came across this issue, when working on an OMPT example for the OpenMP Examples document. Currently, the runtime would print _OPENMP='201611', when exporting OMP_DISPLAY_ENV=1.
This is other than the value of _OPENMP=201511 during compilation. Furthermore, 201611 is not a value defined in any spec.

I had a discussion about OpenMP versions with Michael Klemm (OpenMP CEO / Intel) a while ago. From his perspective OpenMP compiler and runtime should always be seen as one paired thing.
So, if the compiler supports and exposes different behavior for different OpenMP versions, the runtime should be aware of that.

So, if we try to implement differently specified behavior (as suggested by -fopenmp-version=51), the proper thing to do from my perspective would be to pass on the compile time version to the runtime.
The runtime then "could" do specific things at execution time. At least, the runtime would print out the right version string for OMP_DISPLAY_ENV=1.

What do you think about this? How can we make this work?

Best
Joachim

Hi all,

sorry for necromancing on this thread :smiley:

I came across this issue, when working on an OMPT example for the OpenMP Examples document. Currently, the runtime would print _OPENMP='201611', when exporting OMP_DISPLAY_ENV=1.
This is other than the value of _OPENMP=201511 during compilation. Furthermore, 201611 is not a value defined in any spec.

I had a discussion about OpenMP versions with Michael Klemm (OpenMP CEO / Intel) a while ago. From his perspective OpenMP compiler and runtime should always be seen as one paired thing.
So, if the compiler supports and exposes different behavior for different OpenMP versions, the runtime should be aware of that.

So, if we try to implement differently specified behavior (as suggested by -fopenmp-version=51), the proper thing to do from my perspective would be to pass on the compile time version to the runtime.
The runtime then "could" do specific things at execution time. At least, the runtime would print out the right version string for OMP_DISPLAY_ENV=1.

What do you think about this? How can we make this work?

We could encode it in the ident_t which should also solve the issue

with mixing openmp versions during compile time.

What if the code was compiled my multiple compilers?
User can link objects compiled by gcc5, gcc9, clang9, clang10, clang11, icc19, icc19.1, etc. into a single application. Supported version in different objects may not match of cause.

-- Andrey

What if the code was compiled my multiple compilers?
User can link objects compiled by gcc5, gcc9, clang9, clang10, clang11, icc19, icc19.1, etc. into a single application. Supported version in different objects may not match of cause.

Wouldn't my solution take care of that (in the future)?

If there is no OpenMP version in the ident_t struct we say we don't know/are guessing/unsure or something similar.

That may be a partial solution, but still there are problems.

E.g. omp_display_env() does not have ident_t parameter, so if user would print _OPENMP macro and call omp_display_env() at the beginning, the library may not have a chance to get ident_t from compiler. If main program is compiled with -fopenmp then compiler can make internal call to runtime at the beginning, but otherwise printed version may depend on the sequence of OpenMP events in a program, - whether printing of version requested before or after runtime gets info from compiler.

-- Andrey

That may be a partial solution, but still there are problems.

E.g. omp_display_env() does not have ident_t parameter, so if user would print _OPENMP macro and call omp_display_env() at the beginning, the library may not have a chance to get ident_t from compiler. If main program is compiled with -fopenmp then compiler can make internal call to runtime at the beginning, but otherwise printed version may depend on the sequence of OpenMP events in a program, - whether printing of version requested before or after runtime gets info from compiler.

Right, but we would need to actively set (potentially a lot) if we want it to be accurate all the time. What we could do instead is to print something like "5.0 or less" if we don't know (yet) and update it on a best effort basis. Results may vary if you mix things but they will not be totally bananas and we would indicate if we are "estimating".

What if the code was compiled my multiple compilers?
User can link objects compiled by gcc5, gcc9, clang9, clang10, clang11, icc19, icc19.1, etc. into a single application. Supported version in different objects may not match of cause.

I'm not too worried about such scenario, as this is working in unspecified behavior land.
I think, if the application was compiled with an OpenMP compiler, the compile time value of _OPENMP should be printed and also be used for the execution.

If multiple OpenMP objects are linked, probably the first one loaded wins?
A function omp_get_version would actually allow a linked object (like a numerics / BLAS library) to check at runtime, whether the expected OpenMP version is used in the execution. (The method in https://github.com/OpenMP/examples-internal/issues/112 should actually work for any such library)

- Joachim