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

[Yabin Hu]

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/20120509/68fed1d3/attachment.html>