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

Justin Holewinski <justin.holewinski at gmail.com> writes:
> I believe the point Tobias is trying to make is that he wants to
> retain the ability to pipe modules between tools and not worry about
> the modules ever hitting disk, e.g.
>
> opt -load GPUOptimizer.so -gpu-opt | llc -march=x86
> where the module coming in to opt is just unoptimized host code, and the
module coming out of opt has embedded GPU IR.
So you want opt to extract kernels?

In that case, you'll have to replace llc with some external tool that
moves those kernels to separate IR files, invokes llc on them and then
links them back together.

                               -Dave

On 05/08/2012 07:47 PM, dag at cray.com wrote:
> Justin Holewinski<justin.holewinski at gmail.com>  writes:
>
>> I believe the point Tobias is trying to make is that he wants to
>> retain the ability to pipe modules between tools and not worry about
>> the modules ever hitting disk, e.g.
>>
>> opt -load GPUOptimizer.so -gpu-opt | llc -march=x86
>> where the module coming in to opt is just unoptimized host code, and
the module coming out of opt has embedded GPU IR.
>
> So you want opt to extract kernels?
Yes, but not only that.
> In that case, you'll have to replace llc with some external tool that
> moves those kernels to separate IR files, invokes llc on them and then
> links them back together.
I want clang to automatically create executables that use CUDA/OpenCL to 
offload core computations (from plain C code). This should be 
implemented in an external LLVM-IR optimization pass.

clang -Xclang -load -Xclang CUDAGenerator.so file.c -O3 -mllvm -offload-cuda

The very same should work for Pure, dragonegg and basically any compiler 
based on LLVM. So I do not want to change clang at all (except of 
possibly linking to -lcuda).

The llvm.codegen intrinsic allows this, without requiring changes to any 
of the external tools. It works both when outputting assembly, enabling 
direct object file emission and it even works in the mc-jit. All 
alternatives proposed so far, are way more complex and require 
significant changes to each LLVM based compiler.

Tobi

Tobias Grosser <tobias at grosser.es> writes:
> The very same should work for Pure, dragonegg and basically any
> compiler based on LLVM. So I do not want to change clang at all
> (except of possibly linking to -lcuda).
Why is this a requirement?  I think it's completely unrealistic to
expect to be able to do this without driver changes.

If you don't want to change clang, then you'll need an external wrapper
driver to call all the relevant tools.

                               -Dave