JonChesterfield added inline comments.
================
Comment at: llvm/include/llvm/IR/OpenMPKinds.def:186
+///{
+
+#ifndef OMP_IDENT_FLAG
----------------
jdoerfert wrote:
> Meinersbur wrote:
> > jdoerfert wrote:
> > > JonChesterfield wrote:
> > > > Sharing constants between the compiler and the runtime is an
> > > > interesting subproblem. I think the cleanest solution is the one used
> > > > by libc, where the compiler generates header files containing the
> > > > constants which the runtime library includes.
> > > I'd prefer not to tackle this right now but get this done first and
> > > revisit the issue later. OK?
> > I don't think this is a good solution. It means that libomp cannot built
> > built anymore without also building clang. Moreover, the values cannot be
> > changed anyway since it would break the ABI.
> >
> > I'd go the other route: The libomp defines what it's ABI is, the compiler
> > generates code for it.
> This patch doesn't change what we do, just where. The numbers are hard coded
> in clang now. Let's start a discussion on the list and if we come up with a
> different scheme we do it after this landed.
Revisit later sounds good.
@Meinersbur Do you know of an example of a non-llvm compiler using this libomp?
The usual order is build a compiler, then use it to build the runtime
libraries, then the whole package can build other stuff. Provided the compiler
doesn't need any of the runtime libraries (compiler-rt, maths libraries, libomp
etc) itself the system bootstraps cleanly. Especially important when cross
compiling and I suspect the gpu targets in openmp have similarly strict
requirements on the first compiler.
Closely related to that, I tend to assume that the runtime libraries can be
rewritten to best serve their only client - the associated compiler - so if
libomp is used by out of tree compilers I'd like to know who we are at risk of
breaking.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69785/new/
https://reviews.llvm.org/D69785
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
