similar to: [LLVMdev] GPU thread/block/grid size contraints in LLVM PTX backend

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 >>

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 Tong <xerox.time.tech at gmail.com> wrote: > I am wondering that how does the LLVM PTX backend find out the > constraints on executing GPU

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

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of David A. Greene > Sent: Tuesday, August 10, 2010 12:02 PM > To: Che-Liang Chiou > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Upstream PTX backend that uses target > independent code generator if possible > > Che-Liang Chiou <clchiou

Che-Liang Chiou <clchiou at gmail.com> writes: > I surfed their code, and it seems that they didn't use code generator. > That means there design should be similar to CBackend or CPPBackend. > So I guess it can't generate some machine instructions like MAD, > and there are some PTX instruction set features that are hard to exploit > if not using code generator. >

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

Hi David, Thanks for asking. On Mon, Aug 9, 2010 at 3:25 PM, David A. Greene <greened at obbligato.org> wrote: > 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

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

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:

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 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

My implementation of predicated instructions is similar to ARM backend. I traced ARM and PowerPC backend for reference. 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 didn't know how to do that. I agree what Micah said; LLVM's code generator has a

I do not know too much about clang, is opencl publicly supported in clang ? how about cuda ? Thanks Xin

On 7/19/12 1:23 PM, Jim Grosbach wrote: > Not really, no. If you really, really, wanted to do it, you could: 1) Hack the code generator to not use that register. It might be as simple as modifying the TableGen file to not know that the register exists. 2) Use inline asm to put the constant into that register and fetch it from that register. The real question is: what larger goal are you

I have a constant parameter in a LLVM function. Is there a way to reserve a CPU register such that it also holds the value of the parameter in LLVM x86 codegen ? Thanks Xin

Thanks David for the comments. Sorry for the late reply. On Mon, Aug 23, 2010 at 11:52 PM, David A. Greene <greened at obbligato.org> wrote: > 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.

2012/2/24 Xin Tong <xerox.time.tech at gmail.com>: > Hopefully you mean sometime in the evening on 29th. If this is the > case, count me in. Good point, I forgot to select a time :-) What about 19:00? > Thanks Cheers, Rafael

On Thu, Jul 19, 2012 at 2:28 PM, John Criswell <criswell at illinois.edu> wrote: > On 7/19/12 1:23 PM, Jim Grosbach wrote: >> >> Not really, no. > > > If you really, really, wanted to do it, you could: > > 1) Hack the code generator to not use that register. It might be as simple > as modifying the TableGen file to not know that the register exists. In fact

Is there any way to stop this ? /home/socrates/llvm/llvm-3.0.src/benchmarks/powerstone/crc/crc.c:67:1: error: 'main' must return 'int' void main() ^ 1 error generated. Thanks