<div dir="ltr">Artem, <div><br></div><div>With David's <a href="http://reviews.llvm.org/rL265060">http://reviews.llvm.org/rL265060</a>, do you think __nvvm_reflect_anchor is still necessary? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 8, 2016 at 9:37 AM, Yuanfeng Peng via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?<div><span style="font-size:17.6px"><br></span></div><div><span style="font-size:17.6px">Thanks!</span></div><span class="HOEnZb"><font color="#888888"><div><span style="font-size:17.6px">yuanfeng </span><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 5:19 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Apr 7, 2016 at 4:24 PM, Yuanfeng Peng via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br></div><div>I needed to compile a cuda source file (say, <a href="http://a.cu" target="_blank">a.cu</a>) into IR (a.bc), and then merge a.bc with another bitcode file (b.bc, compiled from <a href="http://b.cu" target="_blank">b.cu</a>). So I used <b>llvm-link a.bc b.bc -o c.bc</b></div><div><br></div><div>However, I noticed that an internal function '<b> _ZL21__nvvm_reflect_anchorv() </b>' is defined in both a.bc & b.bc, and when merging these two files, one of the two definitions was renamed to '<b>_ZL21__nvvm_reflect_anchorv.2()</b>', and written into c.bc.</div><div><br></div><div> Then I did <b>llc c.bc -o c.s -march=nvptx ; ptxas c.s -o c.o</b></div><div><b><br></b></div><div>However, ptxas would give the following complaint:</div><div><br></div><div>
<p><span><i>ptxas c.s, line 171; error : Duplicate definition of function '_ZL21__nvvm_reflect_anchorv'</i></span></p>
<p><span><i>ptxas c.s, line 171; fatal : Parsing error near '.2': syntax error</i></span></p><p>So I inspected c.s and found the issue above was caused by the following line:</p><p>
</p><p><span>.<i>func</i></span><i><span> (</span><span>.param</span><span> .</span><span>b32</span><span> </span><span>func_retval0</span><span>) </span><span>_ZL21__nvvm_reflect_anchorv</span><span>.</span><span>2</span><span>() </span><span>// @_ZL21__nvvm_reflect_anchorv.2</span></i></p><p>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 <b>`</b><span style="font-weight:bold">_ZL21__nvvm_reflect_anchorv</span><span style="font-weight:bold">.</span><span style="font-weight:bold">2</span><span><b>()`</b>? Or is that possible to prevent </span><span style="font-weight:bold">_ZL21__nvvm_reflect_anchorv</span><span><b>() </b>from being generated into a.bc & b.bc in the first place? </span>Or is this possible to ask llvm-link to NOT rename <b><span>_ZL21__nvvm_reflect_anchorv(</span><span>) </span></b><span><i>into </i><b>ZL21__nvvm_reflect_anchorv</b></span><b><span>.</span><span>2</span></b><span><b>()</b>? </span></p><p><span><i><br></i></span></p><p><span>Thanks!</span></p><span><font color="#888888"><p><span><i>Yuanfeng Peng </i></span><b> </b></p><p><span><i><br></i></span></p></font></span></div></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>