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

[Justin Holewinski]

On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com> wrote:

> Hi LLVMers,
>
> The attached patch adds a new Intrinsic named "llvm.codegen" to support
> embedded LLVM IR code generation.  **The 'llvm.codegen' intrinsic uses
> the LLVM back ends to generate code for embedded LLVM IR strings. The code
> generation target can be same or different to the one of the parent module.
>
>
> The original motivation inspiring us to add this intrinsic, is to generate
> code for heterogeneous platform. A test case in the patch demos this.  In
> the test case, on a X86 host, we use this intrinsic to transform an
> embedded  LLVM IR into a string of PTX assembly. We can then employ a PTX
>  execution engine ( on CUDA Supported GPU) to execute the newly generated
> assembly and copy back the result later.
>

I have to admit, I'm not sold on this solution.  First, there is no clear
way to pass codegen flags to the back-end.  In PTX parlance, how would I
embed an .ll file and compile to compute_13?  Second, this adds a layer of
obfuscation to the system.  If I look at an .ll file, I expect to see all
of the assembly in a reasonably clean syntax.  If the device code is
squashed into a constant array, it is much harder to read.

Is the motivation for the intrinsic simply to preserve the ability to pipe
LLVM commands together on the command-line, e.g. opt | llc?  I really feel
that the cleaner solution is to split the IR into separate files, each of
which can be processed independently after initial generation.


> The usage of this intrinsic is not limited to code generation for
> heterogeneous platform. It can also help lots of (run-time) optimization
> and security problems even when the code generation target is same as the
> one of the parent module.
>

How does this help run-time optimization?


>
> Each call to the intrinsic has two arguments. One is the LLVM IR string.
> The other is the name of the target architecture. When running with tools
> like llc, lli, etc, this intrinsic transforms the input LLVM IR string  to
> a new string of assembly code for the target architecture firstly. Then
> the call to the intrinsic is replaced by a pointer to the newly generated
> string. After this, we have in our module
>

Is the Arch parameter to llvm.codegen really needed?  Since codegen happens
when lowering the intrinsic, the target architecture must be known.  But if
the target architecture is known, then it should be available in the triple
for the embedded module.


>
>
> ** **
>
> We would like to get the community’s feedback on this so as to make sure
> this patch is as universally applicable as possible.
>
> Thanks a lot!
>
>
> best regards,
>
> Yabin Hu
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120427/798fb298/attachment.html>