llvm dev - Apr 2016 - [GPUCC] how to remove _ZL21__nvvm_reflect_anchorv() automatically?

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 *
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160407/cdefa5d8/attachment.html>

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>

Yeah, '.' is the direct reason for the ptxas failure here.  I'm
curious,
however, about what the purpose of nvvm_reflect_anchorv() is here, and why
does the front-end always generate this function? Since the current PTX
emission doesn't mangle dots, it would be a reasonable workaround for me to
prevent the front-end from generating this function in the first place.
Is there any magic option available to do so?

Thanks!
yuanfeng

On Thu, Apr 7, 2016 at 5:19 PM, Reid Kleckner <rnk at google.com> wrote:
> 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/20160408/d16939d5/attachment.html>