[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