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

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.


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.


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

** **

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120428/a48f97d1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-llvm.codegen-intrinsic.patch
Type: application/octet-stream
Size: 19664 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120428/a48f97d1/attachment.obj>

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-dev/attachments/20120427/798fb298/attachment.html>

Hi Justin,

Thanks very much for your comments.

2012/4/28 Justin Holewinski <justin.holewinski at gmail.com>
> On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com>
wrote:
>
>> 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?
>
We can handle this by provide a new argument (e.g. a string of
properly-configured Target Machine) instead of or in addition to the Arch
type string argument.

> 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.
>
Yes, it is. To preserve such an ability is the main benefit we got from
this intrinsic. It means we needn't to implement another compiler driver or
jit tool for our specific purpose. I agree with you that embedded llvm ir
harms the readability of the .ll file.

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?
>
We implement this intrinsic by learning the implementation style of llvm's
garbage collector related intrinsics which support various GC strategies.
It can help if the ASMGenerator in the patch is revised to be able to
accept various optimization strategies provided by the user of this
intrinsic. Then the intrinsic will do what the user wants to the input code
string. When running the code with lli like jit tools, we can choose one
optimization strategy at run-time. Though haven't supported this currently,
we try to make the design as general as we can. The essential functionality
of this intrinsic is that we get an input code string, transform it into a
target-specific new one then replace the call to the intrinsic.

>  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.
>
Yes. It is better that the target data is set correctly in the embedded
module. It is the user's responsibility to do this.


Thanks again!

best regards,
Yabin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120428/c2412243/attachment.html>