[llvm-dev] [GPUCC] how to remove _ZL21__nvvm_reflect_anchorv() automatically?
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Thu Apr 7 17:19:18 PDT 2016
The actual problem here is that PTX appears to not allow '.' in symbol
names. We should probably just change our PTX emission to mangle dots
somehow.
On Thu, Apr 7, 2016 at 4:24 PM, Yuanfeng Peng via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I needed to compile a cuda source file (say, a.cu) into IR (a.bc), and
> then merge a.bc with another bitcode file (b.bc, compiled from b.cu). So
> I used *llvm-link a.bc b.bc -o c.bc*
>
> However, I noticed that an internal function '* _ZL21__nvvm_reflect_anchorv()
> *' is defined in both a.bc & b.bc, and when merging these two files, one
> of the two definitions was renamed to '*_ZL21__nvvm_reflect_anchorv.2()*',
> and written into c.bc.
>
> Then I did *llc c.bc -o c.s -march=nvptx ; ptxas c.s -o c.o*
>
> However, ptxas would give the following complaint:
>
> *ptxas c.s, line 171; error : Duplicate definition of function
> '_ZL21__nvvm_reflect_anchorv'*
>
> *ptxas c.s, line 171; fatal : Parsing error near '.2': syntax error*
>
> So I inspected c.s and found the issue above was caused by the following
> line:
>
> .*func** (.param .b32 func_retval0) _ZL21__nvvm_reflect_anchorv.2() //
> @_ZL21__nvvm_reflect_anchorv.2*
>
> After I manually deleted the definition of this function in c.s, the
> compilation works file. I wonder how could I force llc to remove *`*
> _ZL21__nvvm_reflect_anchorv.2*()`*? Or is that possible to prevent
> _ZL21__nvvm_reflect_anchorv*() *from being generated into a.bc & b.bc in
> the first place? Or is this possible to ask llvm-link to NOT rename
> *_ZL21__nvvm_reflect_anchorv() **into **ZL21__nvvm_reflect_anchorv**.2*
> *()*?
>
>
> Thanks!
>
> *Yuanfeng Peng *
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160407/05739019/attachment.html>
More information about the llvm-dev
mailing list