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

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.

But Chris has the final say, I think.

                               -Dave

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

Tobias Grosser <tobias at grosser.es> writes:
>> 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.
But why do you need an intrinsic to do that?  Just generate the code to
a file and suck it into a string, maybe with an external "linker"
tool.

If you just want something to work, that should be sufficient.  If you
want some long-term design/implementation I don't think llvm.codegen is
it.
> 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.
We already have the Linker.

                                -Dave

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