[Openmp-dev] Sharing enums between llvm and openmp

[Doerfert, Johannes via Openmp-dev]

On 12/30, Doerfert, Johannes via Openmp-dev wrote:
> We should do something here, I have a very strong preference what but so
> far not the time.
> 
> On 12/30, Jon Chesterfield via Openmp-dev wrote:
> > This email motivated by D71948, but the question has come up before
> > without resolution.
> > 
> > The compiler and runtime need to agree on various things. Values of enums,
> > other constants, typedefs, prototype of functions. Currently we achieve
> > that through careful programming and review which is slow and a bit fragile.
> > 
> > I don't think building the compiler should depend on the openmp runtime
> > source (so the compiler can build without openmp).
> > 
> > Someone in a previous review didn't want building the runtime to depend on
> > the compiler source (so that the runtime can be easily built with other
> > compilers).
> 
> I don't see this problem. If you download the runtime you have the llvm
> source.

It was pointed out to me that there is a release tarball with only the
runtime code which builds without llvm-core. If supporting that usage
model is important we can copy the OMPKinds.def file as part of the
release packaging process into the tarball.

> > Options seem to be:
> > 1/ Status quo - copy/paste/hope. This is working for us but I don't like
> > the hope part
> > 2/ Put header files somewhere outside of the llvm / openmp / clang projects
> > and include
> > 3/ Put header file in the compiler and include it from openmp
> > 4/ Put header file in openmp and include it from the compiler
> > 5/ Other?
> > 
> > I think we should create llvm/CodeGen/OpenMPConstants.h under the llvm tree
> > and use that. This will fractionally inconvenience downstream people using
> > llvm's bundled openmp library without llvm in that they'll have to copy the
> > file out of the llvm tree. That seems fine.
> 
> 3/ is the right way, except that it is not "a header" per se. The
> "source of truth" is `llvm/lib/Frontend/OpenMP/OMPKinds.def`. Not all
> constants are defined in their yet but we are getting there. I tried to
> make sure "numerical values" in their already match the runtime
> definitions. The last step that is missing is to use things like
> `OMP_PROC_BIND_KIND` in the definition of `omp_proc_bind_t` (omp.h.var)
> and `kmp_proc_bind_t` (kmp.h). That would look like the `ProcBindKind`
> definition in `llvm/include/llvm/Frontend/OpenMP/OMPConstants.h`. Thus,
> 
> typedef enum omp_proc_bind_t {
> #define OMP_PROC_BIND_KIND(Enum, Str, Value) Enum = Value;
> #include "llvm/Frontend/OpenMP/OMPKinds.def"
> } omp_proc_bind_t;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20191230/acb5149f/attachment.sig>