[Openmp-commits] [PATCH] D69857: [libomptarget] Replace INLINE with DEVICE to work around nvcc deleting forceinline symbols
Alexey Bataev via Phabricator via Openmp-commits
openmp-commits at lists.llvm.org
Tue Nov 5 12:38:43 PST 2019
ABataev added a comment.
In D69857#1734592 <https://reviews.llvm.org/D69857#1734592>, @JonChesterfield wrote:
> In D69857#1734569 <https://reviews.llvm.org/D69857#1734569>, @ABataev wrote:
>
> > In D69857#1734561 <https://reviews.llvm.org/D69857#1734561>, @JonChesterfield wrote:
> >
> > > In D69857#1734541 <https://reviews.llvm.org/D69857#1734541>, @ABataev wrote:
> > >
> > > > This one ends up with the multiply defined symbols instead :)
> > >
> > >
> > > How? The functions are only defined in support.cu and it's only compiled once. Where are the duplicates from?
> >
> >
> > No idea, llvm-link reports multiply defined functions.
>
>
> Why is llvm-link involved? I thought nvcc generated object files (ptxas, possibly sass).
>
> I believe there are two compilation paths in the nvptx cmake. One includes everything into unity.cu and passes that to nvcc, which builds a single object file. The other builds each file individually with clang and passes the result to llvm-link. The most likely explanation at this point is that I've totally misunderstood what the cmake files is supposed to be doing, and thus failed to modify it appropriately.
.bc files are linked with llvm-link. the library is compiled by both, nvcc (to generate .a library) and clang + llvm tools (to generate .bc library). .bc is used for generating of the most optimal code with inlined runtime library.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69857/new/
https://reviews.llvm.org/D69857
More information about the Openmp-commits
mailing list