similar to: [LLVMdev] [PATCH][RFC] Add llvm.codegen Intrinsic To Support Embedded LLVM IR Code Generation

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

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

On 04/28/2012 10:25 AM, Yabin Hu wrote: > Hi Justin, > > Thanks very much for your comments. > > 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com > <mailto:justin.holewinski at gmail.com>> > > On Fri, Apr 27, 2012 at 7:40 PM, Yabin Hu <yabin.hwu at gmail.com > <mailto:yabin.hwu at gmail.com>> wrote: > > The

Hi Evan, Thanks for your time. 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. > I think the embedded string in

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

On Sat, Apr 28, 2012 at 8:27 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 04/28/2012 04:30 PM, Justin Holewinski wrote: > >> 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. >> >> >> I think we

On Sat, Apr 28, 2012 at 3:16 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 04/28/2012 10:25 AM, Yabin Hu wrote: > >> Hi Justin, >> >> Thanks very much for your comments. >> >> 2012/4/28 Justin Holewinski <justin.holewinski at gmail.com >> <mailto:justin.holewinski@**gmail.com <justin.holewinski at gmail.com>>> >>

On 04/29/2012 01:21 AM, Justin Holewinski wrote: > > > On Sat, Apr 28, 2012 at 8:27 AM, Tobias Grosser <tobias at grosser.es > <mailto:tobias at grosser.es>> wrote: > regalloc= is different. It is global and consequently influences > both host and device code generation. However, to me it is rather a > debugging option. It is never set by clang and

On Apr 29, 2012, at 6:37 AM, Tobias Grosser wrote: > > OK, I get what you mean. The intrinsic is currently targeted at the > OpenCL/CUDA model. It is the most widely used. Stuff like cell sounds > interesting, but probably needs further thoughts. Even with OpenCL/CUDA, > this intrinsic works currently only for PTX code generation, but I hope > we can gain support for other

Tobias Grosser <tobias at grosser.es> writes: >> Doesn't LLVM support taking the address of a function in another address >> space? If not it probably should. > > Hi Dave, > > I highly appreciate your idea of integrating heterogeneous computing > features directly into LLVM-IR. I believe this can be a way worth > going, but I doubt now is the right moment

On 04/29/2012 08:28 PM, Evan Cheng wrote: > > On Apr 29, 2012, at 6:37 AM, Tobias Grosser wrote: > >> >> OK, I get what you mean. The intrinsic is currently targeted at the >> OpenCL/CUDA model. It is the most widely used. Stuff like cell sounds >> interesting, but probably needs further thoughts. Even with OpenCL/CUDA, >> this intrinsic works currently only

On 05/01/2012 11:21 PM, dag at cray.com wrote: > Justin Holewinski<justin.holewinski at gmail.com> writes: > >> For something like PTX, runtime calls take care of the call semantics so >> it is either up to the user or the frontend to set up the runtime calls >> correctly. We don't need to completely solve this problem. Yet. :) >> >>

Tobias Grosser <tobias at grosser.es> writes: > To write optimizations that yield embedded GPU code, we also looked into > three other approaches: > > 1. Directly create embedded target code (e.g. PTX) > > This would mean the optimization pass extracts device code internally > and directly generate the relevant target code. This approach would > require our

On 05/07/2012 06:07 PM, dag at cray.com wrote: > Tobias Grosser<tobias at grosser.es> writes: > >>> Doesn't LLVM support taking the address of a function in another address >>> space? If not it probably should. >> >> Hi Dave, >> The llvm.codegen intrinsic seems the perfect match to build up such >> experience. It requires no changes to

Justin Holewinski <justin.holewinski at gmail.com> writes: > For something like PTX, runtime calls take care of the call semantics so > it is either up to the user or the frontend to set up the runtime calls > correctly. We don't need to completely solve this problem. Yet. :) > > But there has to be some interface that allows an LLVM IR function > from

Hi all, I am a phd student from Huazhong University of Sci&Tech, China. The following is my GSoC 2012 proposal. Comments are welcome! *Title: Automatic GPGPU Code Generation for LLVM* *Abstract* Very often, manually developing an GPGPU application is a time-consuming, complex, error-prone and iterative process. In this project, I propose to build an automatic GPGPU code generation framework

Hi Tobi, 2012/4/28 Tobias Grosser <tobias at grosser.es> > 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

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 >

On Mon, Apr 30, 2012 at 12:55 PM, <dag at cray.com> wrote: > Tobias Grosser <tobias at grosser.es> writes: > > > To write optimizations that yield embedded GPU code, we also looked into > > three other approaches: > > > > 1. Directly create embedded target code (e.g. PTX) > > > > This would mean the optimization pass extracts device code

Hi Yabin, Instead of compile the LLVM IR to PTX asm string in a ScopPass, you can also the improve llc/lli or create new tools to support the code generation for Heterogeneous platforms[1], i.e. generate code for more than one target architecture at the same time. Something like this is not very complicated and had been implemented[2,3] by some people, but not available in LLVM mainstream.