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

[Yuanfeng Peng via llvm-dev]

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>