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

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.

Unless Chris says otherwise, we can consider this proposal dead. Sorry.

Evan

On May 7, 2012, at 2:13 PM, Tobias Grosser wrote:
> On 05/07/2012 06:13 PM, dag at cray.com wrote:
>> Tobias Grosser<tobias at grosser.es>  writes:
>> 
>>> Would you dump the assembly of the different modules to stdout or
do
>>> you want to support multiple -o options to specify the various
output
>>> files?
>> 
>> I forgot to address this one.  With current OpenCL and CUDA
>> specifications, there's no need to do multiple .o files.  In my
mind,
>> llc should output one .o (one .s, etc.).  Anything else wreaks havoc on
>> build systems.
> 
> Yes, that's what I am advocating for. There is no need for all this 
> complexity. Both standards store the embedded code as a string in the 
> host module. That is exactly what the llvm.codegen intrinsic models. It 
> requires zero further changes to the code generation backend.
> 
> In contrast, extending LLVM-IR to support heterogeneous modules requires 
> us to add logic to the llvm code generation that knows how to link the 
> different sub-modules.
> 
> Tobi
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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.

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?

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?

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

Tobias Grosser <tobias at grosser.es> writes:
> 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. 
That's simply not true.  I outlined how you can accomplish your task
without any IR changes at all.  IR changes are only necessary (probably)
if we want opt or some other tool to extract accelerator kernels.  And
even then I'm not 100% sure we need IR changes.

                          -Dave

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
>