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

David's change makes nvvm_reflect_anchor unnecessary. The issue with dots
in names generated by llvm still needs to be fixed.
On Apr 9, 2016 8:32 AM, "Jingyue Wu" <jingyue at google.com>
wrote:
> Artem,
>
> With David's http://reviews.llvm.org/rL265060, do you think
> __nvvm_reflect_anchor is still necessary?
>
> On Fri, Apr 8, 2016 at 9:37 AM, Yuanfeng Peng via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/20160409/58d14c2d/attachment.html>

r267062 removed __nvvm_reflect_anchor() so you should no longer see this
particular manifestation of illegal-character-in-PTX problem.

--Artem

On Sat, Apr 9, 2016 at 12:48 PM, Artem Belevich <tra at google.com> wrote:
> David's change makes nvvm_reflect_anchor unnecessary. The issue with
dots
> in names generated by llvm still needs to be fixed.
> On Apr 9, 2016 8:32 AM, "Jingyue Wu" <jingyue at
google.com> wrote:
>
>> Artem,
>>
>> With David's http://reviews.llvm.org/rL265060, do you think
>> __nvvm_reflect_anchor is still necessary?
>>
>> On Fri, Apr 8, 2016 at 9:37 AM, Yuanfeng Peng via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> 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
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>

-- 
--Artem Belevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160421/d8faceaf/attachment.html>

Awesome!  Thanks for letting me know, Artem!

yuanfeng
> On Apr 21, 2016, at 3:09 PM, Artem Belevich <tra at google.com>
wrote:
> 
> r267062 removed __nvvm_reflect_anchor() so you should no longer see this
particular manifestation of illegal-character-in-PTX problem.
> 
> --Artem
> 
> On Sat, Apr 9, 2016 at 12:48 PM, Artem Belevich <tra at google.com
<mailto:tra at google.com>> wrote:
> David's change makes nvvm_reflect_anchor unnecessary. The issue with
dots in names generated by llvm still needs to be fixed.
> 
> On Apr 9, 2016 8:32 AM, "Jingyue Wu" <jingyue at google.com
<mailto:jingyue at google.com>> wrote:
> Artem, 
> 
> With David's http://reviews.llvm.org/rL265060
<http://reviews.llvm.org/rL265060>, do you think __nvvm_reflect_anchor is
still necessary?
> 
> On Fri, Apr 8, 2016 at 9:37 AM, Yuanfeng Peng via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 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
<mailto: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 <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi,
> 
> I needed to compile a cuda source file (say, a.cu <http://a.cu/>)
into IR (a.bc), and then merge a.bc with another bitcode file (b.bc, compiled
from b.cu <http://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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> 
> 
> 
> -- 
> --Artem Belevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160421/1e67badb/attachment.html>