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

[Evan Cheng]

On May 8, 2012, at 2:08 AM, Tobias Grosser wrote:

> On 05/08/2012 05:13 AM, Evan Cheng wrote:
>> Sorry Tobias, I'm not in favor of this change. From what I can tell, this enables some features which can implemented via other means. It adds all kinds of complexity to LLVM and I'm also highly concerned about bitcode that can embed illegal (or worse malicious) code using this feature.
> 
> Hi Evan,
> 
> there is no need to force this change in. I am rather trying to understand the shortcomings of my approach and look for possible better solutions.

Hi Tobias,

When you are proposing a significant extension to LLVM, the burden is on the person who is proposing the change to convince folks there is a significant advantage to LLVM developers / users who relay on LLVM mainline.

> 
> That's why I was asking you where you see the possibility of illegal/malicious code? You did not really explain it yet and I would
> be more than happy to be understand such a problem. From my point of view embedded and host module code are both compiled at the same time and are both checked by the LLVM bitcode verifier. How could this introduce any malicious code, that could not be introduced by normal LLVM-IR?

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.

> 
> In terms of the complexity. The only alternative proposal I have heard of was making LLVM-IR multi module aware or adding multi-module support to all LLVM-IR tools. Both of these changes are way more complex than the codegen intrinsic. Actually, they are soo complex that I doubt that they can be implemented any time soon. What is the simpler approach you are talking about?

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). Given how specific your need is, it's just not appropriate for LLVM mainline.

Evan


> 
> Maybe I completely missed the point, but if there would be a good alternative there would be no need to discuss. I would happily go ahead and implement the said alternative. Even if there is non I would keep quiet, after I understand the concerns that block this proposal. For now, I don't think I understood the concerns yet.
> 
> Cheers
> Tobi
>