<div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <span dir="ltr"><<a href="mailto:yabin.hwu@gmail.com" target="_blank">yabin.hwu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font face="nsimsun, monospace">Hi LLVMers,</font></span><div><span><font face="nsimsun, monospace"><br></font></span></div><div><p class="MsoNormal"><font face="nsimsun, monospace">The attached patch adds a new Intrinsic named "llvm.codegen" to support embedded LLVM IR code generation. <u></u><span style="background-color:transparent;text-align:left">The '</span><tt style="background-color:transparent;text-align:left">llvm.codegen</tt><span style="background-color:transparent;text-align:left">' intrinsic uses the LLVM back ends to generate code for embedded LLVM IR strings. The code generation target can be same or different to the one of the parent module. </span></font></p>
<p class="MsoNormal"><font face="nsimsun, monospace"><span style="background-color:transparent;text-align:left"><br></span></font></p><p class="MsoNormal"><font face="nsimsun, monospace" style="color:rgb(34,34,34)">The original motivation inspiring us to add this intrinsic, is to generate code for heterogeneous platform. A test case in the patch demos this. In the test case, on a X86 host, we use this intrinsic to transform an embedded LLVM IR into a string of PTX assembly. We can then employ a PTX execution engine ( on </font><span style="color:rgb(34,34,34);font-family:nsimsun,monospace">CUDA Supported GPU</span><font face="nsimsun, monospace" style="color:rgb(34,34,34)">) to execute the newly generated assembly and copy back the result later.</font></p>
</div></blockquote><div><br></div><div>I have to admit, I'm not sold on this solution. First, there is no clear way to pass codegen flags to the back-end. In PTX parlance, how would I embed an .ll file and compile to compute_13? Second, this adds a layer of obfuscation to the system. If I look at an .ll file, I expect to see all of the assembly in a reasonably clean syntax. If the device code is squashed into a constant array, it is much harder to read.</div>
<div><br></div><div>Is the motivation for the intrinsic simply to preserve the ability to pipe LLVM commands together on the command-line, e.g. opt | llc? I really feel that the cleaner solution is to split the IR into separate files, each of which can be processed independently after initial generation.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p class="MsoNormal"><font face="nsimsun, monospace"><br></font></p><p class="MsoNormal"><span style="font-family:nsimsun,monospace">The usage of t</span><font face="nsimsun, monospace">his intrinsic is not limited to code generation for heterogeneous platform. It can also help lots of (run-time) optimization and security problems even when the code generation target is same as the one of the parent module.</font></p>
</div></blockquote><div><br></div><div>How does this help run-time optimization?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p class="MsoNormal"><font face="nsimsun, monospace"><br></font></p><p class="MsoNormal"><font face="nsimsun, monospace"><span style="background-color:transparent;text-align:left">Each call to the intrinsic has two arguments. One is the LLVM IR string. The other is the name of the target architecture. When running with tools like llc, lli, etc, this intrinsic transforms the input LLVM IR string to a new string of assembly code for the target architecture </span></font><span style="background-color:transparent;text-align:left;font-family:nsimsun,monospace">firstly. Then the call to the intrinsic is replaced by a pointer to the newly generated string. After this, we have in our module</span></p>
</div></blockquote><div><br></div><div>Is the Arch parameter to llvm.codegen really needed? Since codegen happens when lowering the intrinsic, the target architecture must be known. But if the target architecture is known, then it should be available in the triple for the embedded module.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p class="MsoNormal"><span style="background-color:transparent;text-align:left;font-family:nsimsun,monospace"> </span></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">We would like to get the community’s feedback on this so as to make sure this patch is as universally applicable as possible. </p><p class="MsoNormal">
Thanks a lot!</p><p class="MsoNormal"><br></p><p class="MsoNormal">best regards,</p><p class="MsoNormal">Yabin Hu</p></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>
</div>