[Openmp-commits] [PATCH] D133277: [RFC][OpenMP][Doc] No backward compatible for libomptarget and plugins

Joseph Huber via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Thu Sep 8 09:02:52 PDT 2022


jhuber6 added a comment.

In D133277#3774954 <https://reviews.llvm.org/D133277#3774954>, @dreachem wrote:

> @tianshilei1992 Can you explain a bit more what is the motivation here? Does requiring a new entry point rather than changing the interface for a pre-existing entry point create problems? The Cray compiler doesn't use libomptarget, but it does use the interface. It is also designed to support interoperability with other LLVM-based compilers, which may be based on a newer version of LLVM. Backwards compatibility with the libomptarget interface is needed for that to work (not necessary for the plugins).

Currently we attempt to maintain backwards compatibility with old programs being run with a new `libomptarget` build. We do this by keeping around the legacy function interfaces, even if they are slower now. This was never an explicitly stated goal guarantee , but it has some benefits for users on clusters switching versions of LLVM without needing to recompile. Now that we have made `libomptarget` and the plugins an `LLVM` library we use versioned libraries, e.g. `libomptarget.so` is a symbolic link to `libomptarget.so.16`. LLVM isn't backwards compatible between versions, so if users require an older version they can stick with the versioned library that they require. The argument is that we should do the same with `libomptarget` as this would allow us to make useful changes to the binary and remove some legacy interfaces. We could keep the old entries into libomptarget, but there are some we'd like to change. For example, I would like to remove the `omp.register_requires` function and replace it with a new interface. This would be a breaking change if we expect backward compatibility as the old function would either not exist or be a no-op. I would like the ability to make changes like this, I'm not exactly sure what CUDA's backwards compatibility method is between CUDA releases, we may be able to compare policies for what users expect.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133277/new/

https://reviews.llvm.org/D133277



More information about the Openmp-commits mailing list