similar to: [LLVMdev] GSoC: PTX Back-End for LLVM

On 03/28/2011 09:00 PM, 陳韋任 wrote: > Hi, Justin > >> I am going to submit a GSoC proposal for LLVM this year, and I would like to >> first post it here to get constructive feedback before I submit it before >> the April 8 deadline. This is the first time I have submitted a GSoC >> proposal, so please be brutal with the feedback. :) > > Can I join this

Hi, Justin > I am going to submit a GSoC proposal for LLVM this year, and I would like to > first post it here to get constructive feedback before I submit it before > the April 8 deadline. This is the first time I have submitted a GSoC > proposal, so please be brutal with the feedback. :) Can I join this project, if possible? I am also interested in PTX backend. Regards, chenwj

On Mon, Mar 28, 2011 at 10:19 PM, Tobias Grosser <grosser at fim.uni-passau.de>wrote: > On 03/28/2011 09:12 AM, Justin Holewinski wrote: > >> Hi All, >> >> I am going to submit a GSoC proposal for LLVM this year, and I would >> like to first post it here to get constructive feedback before I submit >> it before the April 8 deadline. This is the first

On 03/28/2011 09:12 AM, Justin Holewinski wrote: > Hi All, > > I am going to submit a GSoC proposal for LLVM this year, and I would > like to first post it here to get constructive feedback before I submit > it before the April 8 deadline. This is the first time I have submitted > a GSoC proposal, so please be brutal with the feedback. :) Hi Justin, I think this is a great

Hi Justin, There are some backward incompatible features of PTX; for example, special registers are redefined as v4i32 (they were v4i16) in PTX 2.0. And CUDA 4.0 was rolled out last week. I heard that some instructions are deprecated. I am not sure how stable (or unstable) PTX specification is. Do you have a rough assessment of its stability? If PTX specification is still fast evolving, I would

Hi, The PTX backend we developed (CBackend approach, does not use the target independent code generator) is already more advanced. An older version is published here: http://sourceforge.net/projects/llvmptxbackend/ We recently eliminated a bug which increased the number of required registers per thread. Surprisingly, without that bug the generated code is already comparable to code generated

Hi Justin, I am upstreaming the PTX backend. My plan is to have a working prototype (that mean you may compile non-trivial code with some workarounds) by the end of this year or by January 2011. I hope I could catch up next release of LLVM (version 2.9), so I will adjust my plan according to the release schedule once it is announced. Regards, Che-Liang On Wed, Oct 6, 2010 at 11:16 PM, Justin

Hi there, I have a working prototype of PTX backend, and I would like to upstream it if possible. This backend is implemented by LLVM's target independent code generator framework; I think this will make it easier to maintain. I have tested this backend to translate a work-efficient parallel scan kernel ( http://http.developer.nvidia.com/GPUGems3/gpugems3_ch39.html ) into PTX code. The

I read on the archives that a PTX back-end was discussed around August and I see that some initial code has been checked into LLVM trunk. What is the status of this project? Is it being actively worked on? I am ultimately interested in using LLVM for GPU code optimization/generation and am very interested in this particular project. -- Thanks, Justin Holewinski -------------- next part

Che-Liang Chiou <clchiou at gmail.com> writes: > Hi there, > > Thank Nick for kindly reviewing the patch. Here is the link to the > source code of the PTX backend; it would help Nick review the patch. > http://lime.csie.ntu.edu.tw/~clchiou/llvm-ptx-backend.tar.gz Great! > I decided to take the code generator approach (referred to as codegen > approach) rather than C

2011/5/13 Dan Bailey <drb at dneg.com> > Justin Holewinski wrote: > > On Fri, May 13, 2011 at 5:11 AM, Dan Bailey <drb at dneg.com> wrote: > >> That's fine with me. Unless there's a particular reason for it I would >> suggest perhaps changing the immediate syntax as well to swap it round, so >> it would be Immi32, Immi64, Immf32, etc. It

On Fri, May 13, 2011 at 5:11 AM, Dan Bailey <drb at dneg.com> wrote: > That's fine with me. Unless there's a particular reason for it I would > suggest perhaps changing the immediate syntax as well to swap it round, so > it would be Immi32, Immi64, Immf32, etc. It doesn't bother me that much the > way it currently is, but when there are lots of operations taking a

Che-Liang Chiou <clchiou at gmail.com> writes: > Hi there, > > I have a working prototype of PTX backend, and I would like to > upstream it if possible. This backend is implemented by LLVM's target > independent code generator framework; I think this will make it easier > to maintain. How does this relate, at all, to the backend here:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Justin Holewinski wrote: <blockquote cite="mid:BANLkTi=Y9EFmWRu-9dQxydq8zTyF7tEbJw@mail.gmail.com"

Hi there, Thank Nick for kindly reviewing the patch. Here is the link to the source code of the PTX backend; it would help Nick review the patch. http://lime.csie.ntu.edu.tw/~clchiou/llvm-ptx-backend.tar.gz The source code from above link is a working prototype. So it will not be upstreamed as is; I will refactor and add unimplemented features while upstreaming it. That said, the source code

Ah, that's helpful. I knew that I'd need to end up with PTX as text, not a true binary, but I would have figured that it would come out of MCJIT. Thanks for helping to steer me away from the wrong trail. OK, one more question: Can anybody clarify the pros and cons of generating the PTX through the standard LLVM distro, versus using the "libnvvm" that comes with the Cuda SDK?

but does it have default values ? Thanks Xin On Tue, Mar 13, 2012 at 5:19 AM, Che-Liang Chiou <clchiou at gmail.com> wrote: > You specify shader model, bit size and etc. arch-specified parameters > though -march, -mattr and -mcpu, but AFAIK, PTX backend does not use > the GPU thread/block/grid size information in optimization yet. > > On Mon, Mar 12, 2012 at 8:17 PM, Xin

I don't think so, but you should check source code. On Tue, Mar 13, 2012 at 9:58 PM, Xin Tong <xerox.time.tech at gmail.com> wrote: > but does it have default values ? > > Thanks > > Xin > > On Tue, Mar 13, 2012 at 5:19 AM, Che-Liang Chiou <clchiou at gmail.com> wrote: >> You specify shader model, bit size and etc. arch-specified parameters >>

Hello Bergström/Eric, Thanks for the reply. The G80(sm_10) architecture was ported on FPGA by a group of researchers (http://www.ecs.umass.edu/ece/tessier/andryc-fpt13.pdf). Our group have some further research interest on this work. I was working on modifying the Clang-LLVM for a couple of months and achieved the required changes. But Clang-LLVM is only allowing me to generate PTX for sm_20,

Che-Liang Chiou <clchiou at gmail.com> writes: > My implementation of predicated instructions is similar to ARM > backend. I traced ARM and PowerPC backend for reference. Cool. > If, David, you were saying a implementation of predication in LLVM IR, > I didn't do that. It was partly because I was not (and is still not) > very familiar with LLVM's design; so I