[Openmp-dev] Sharing enums between llvm and openmp

[Roman Lebedev via Openmp-dev]

On Tue, Dec 31, 2019 at 12:05 AM Doerfert, Johannes via Openmp-dev
<openmp-dev at lists.llvm.org> wrote:
>
> 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.
For the record, i'm a fan of this cleanup, but not a fan of this solution
as it increases coupling between components - right now there is
no dependency on llvm from openmp/, but there will be one now.

I believe there is a rather straight-forward solution to avoid it:
by having byte-for-byte identical files in both LLVM and in openmp/,
and having a build target that fails if files mismatch.

To be noted there's preexisting art in similar duplication,
although with none of sanity checking - compiler-rt cpu detection,
some sanitizer stuff between clang and compiler-rt.
Also, IIRC unwind code is duplicated between libunwind and elsewhere.

Roman.

> > > 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;
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev