[LLVMdev] [PATCH][RFC] Add llvm.codegen Intrinsic To Support Embedded LLVM IR Code Generation

[Evan Cheng]

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. 

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. 

I'm sorry for taking a hard line on this. But the decision is clearly a no unless Chris says otherwise. 

Evan

On May 8, 2012, at 7:39 PM, Yabin Hu <yabin.hwu at gmail.com> wrote:

> Hi Evan,
> 
> Thanks for your time.
> 
> 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.
> 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. 
>  
> 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). 
> 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.
> 
> Thanks,
> Yabin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120508/51b409a2/attachment.html>