Hi Evan,<br><br>Thanks for your time.<div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You're adding a feature that embed code inside a module. When the module is loaded, is the string going to be verified? How are users of LLVM IR able to ensure the embedded string is safe? I am not saying it cannot be done. This feature just increases the risk and that again raises the bar for acceptance.<br>
</blockquote><div>I think the embedded string in the form of a "string" is never harmful. When the module is loaded, the string may not be verified, just like any other "normal" strings in the module. When we transform the embedded string into a piece of "code" temporarily, the intrinsic verify the loading process just like what we do when loading a module from a file.  So I don't think this adds additional security problems. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We don't need multi-module either. The system you are designing should be able to handle multiple bitcode files with multiple modules. I don't claim to know the specifics of your projects. But it seems to be you want this new complexity to LLVM to simplify your tools (single .o rather than multiple). <br>
</blockquote><div>As Tobias explained before, if any llvm-based compiler wants to add a feature of generating code for heterogeneous platform (e.g. CPU+GPU) or employ an optimization pass like ours, this intrinsic helps. They needn't revise their compiler driver too much and needn't add a new linker between host bitcode file and device bitcode file (or some others).  What they need do is to prepare the device code as a string of llvm IR and add a call to the intrinsic. We believe that there is no need for all these external tools to be changed if we can avoid this by adding a new and light weight intrinsic.</div>
<div><br></div><div>Thanks,</div><div>Yabin</div></div></div>