search for: chiou

> -----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 at gmail.com> writes: > > > I surfed their code, and it seems that they didn't use code > generato...

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, Xi...

...y fails, since users use their old passwords instead of the new ones... I wonder whether I am the only one who is experiencing this problem and whether somebody knows how to solve this problem. I can send the logs (nmbd.log, smbd.log and log.machinename) if somebody needs them. Thanks, Angel Chiou

...M, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----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 at gmail.com> writes: >> >> > I surfed their code, and it seems that they didn...

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

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

...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. :) Additionally, Che-Liang Chiou (the code owner of the PTX back-end) has agreed to be my mentor if this is accepted. What does he need to do to become an official mentor? ======== Overview ======== The NVidia Parallel Thread eXecution (PTX) language is an assembly-like language that is used as an intermediate format for all...

Hi Jakob and David, The for-loop inside multiclass definition does not have to add extra abstraction layer. As in the pseudo codes that David wrote earlier (see below), it only condenses the repetitive 'def' statements inside the multiclass definition into a more compact and less copy-paste style form, instead of encapsulating them somewhere outside the multiclass definition. I believe

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 generator framework; I think this will make it...

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

On Oct 8, 2011, at 6:19 AM, Che-Liang Chiou wrote: > I understand if you don't want an extra layer of abstraction (which > adds extra looking-ups to someone reading td files), but I think we > can have for-loop inside a multiclass without abstractions. > > -------------------- > multiclass sse_binop<opcode> { &g...

Hi, Justin Thansk, but I have a little concern though. I saw Chiou mentioned the compatibility issue of PTX on the mailing list. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/038654.html In my PTX.td patch, def FeaturePTX23 : SubtargetFeature<"ptx23", "PTXVersion", PTX_VERSION_2_3", &quot...

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

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

The TableGen language seems to be growing Lisp macros from two different directions. Che-Liang Chiou added a preprocessor with for loops, and David Greene added multidefs. It seems that some kind of macro facility is needed, perhaps we should discuss what it is supposed to look like? /jakob

...tions are you planning to do? If you want to apply high level (on llvm bitcode) optimizations, you can start with our PTX backend and shwitch over to the new backend approach later on (If it turns out that the new approach is really faster). best, Helge Am 06.10.2010 17:39, schrieb Che-Liang Chiou: > 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 wil...

...em in the same way might be a little more consistent? Personally, I think I also might prefer an underscore to make it more readable for new users (Reg_u32, Reg_pred, Imm_i32, Imm_f32, etc). That's maybe just my own preference, so feel free to do it as you've suggested! Dan Che-Liang Chiou wrote: > Hi, > > Current register class naming has a confusing prefix letter 'R' (it is > my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit > registers). > > I propose a 'Reg' + type name naming convention for register classes; such as: >...

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. >> http://lime.csie.ntu.edu.tw/~clchiou/llvm-ptx-backend.tar.gz >...

Hi, Current register class naming has a confusing prefix letter 'R' (it is my bad), such as the first 'R' of RRegu32 (for unsigned 32-bit registers). I propose a 'Reg' + type name naming convention for register classes; such as: Regu16, Regu32, Regf32, Regf64 With one exception for predicate registers (capitalized first letter of 'pred'): RegPred Since

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