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).
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.
What do we prefer?
Thanks!
Jon
We should do something here, I have a very strong preference what but so
far not the time.
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.
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;
Cheers,
Johannes
We should do something here, I have a very strong preference what but so
far not the time.
> 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.
> We should do something here, I have a very strong preference what but so
> far not the time.
>
> > 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.