search for: nvvm_reflect_anchorv

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! y...

...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 o...

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 compl...