<html><head></head><body bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">Please understand you are proposing a feature that *everyone* will be affected.The feature you are proposing introduce significant complexities to LLVM. The only real benefit is it reduces changes to existing tools for heterogeneous platforms. That's not a strong argument. </span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><br></span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">Adding a string to embed llvm module means the bitcode file cannot be easily per-checked. You are leaving the runtime checking to specific implementations. That makes llvm bit code inherently less safe. Thats a no no. </span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);"><br></span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">I'm sorry for taking a hard line on this. But the decision is clearly a no unless Chris says otherwise. </span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);"><br></span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">Evan<br></span><br>On May 8, 2012, at 7:39 PM, Yabin Hu <<a href="mailto:yabin.hwu@gmail.com">yabin.hwu@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>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></div></blockquote><div><blockquote type="cite"><div><div><div class="gmail_quote">
<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>
</div></blockquote></div></body></html>