search for: llvmptxbackend

Hi, finally we changed the license of the PTX-backend from GPL to BSD(license of llvm). You can get the latest version here: https://sourceforge.net/projects/llvmptxbackend/ It should be compatible to the current llvm svn trunk. (revision 110329, Thu 05 Aug 2010) The backend now uses the address space attribute of LLVM for local, global, ... and constant address space. However the clang frontend handles address space attributes incorrectly. Thus writing the input cod...

...dicates (handling all the > representation, etc. in the target-specific codegen)? > > I've have been wanting to see predicates (vector and scalar) in the > LLVM IR for a long time. Perhaps the PTX backend is an opportunity > to explore that. [Villmow, Micah] From looking at the llvmptxbackend, it does not fully support vector types. This in my perspective is one of the greatest benefits of the backend code-generator, automatic support for vector types in LLVM-IR that are not natively supported by the target machine via vector splitting. > > -Dave >...

...ld 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: > > http://sourceforge.net/projects/llvmptxbackend/ > > If they are unrelated, can you do a comparison of the two?  Perhaps > there are holes in each that can be filled by the other.  It would be > a shame to have two completely different PTX backends. > I surfed their code, and it seems that they didn't use code generator. That...

...type 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: http://sourceforge.net/projects/llvmptxbackend/ If they are unrelated, can you do a comparison of the two? Perhaps there are holes in each that can be filled by the other. It would be a shame to have two completely different PTX backends. > I have tested this backend to translate a work-efficient parallel scan > kernel ( http://http.d...

...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: >> >> http://sourceforge.net/projects/llvmptxbackend/ >> >> If they are unrelated, can you do a comparison of the two? Perhaps >> there are holes in each that can be filled by the other. It would be >> a shame to have two completely different PTX backends. >> >> > I surfed their code, and it seems that th...

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 by the official nvcc copiler. Of cause the nvcc compiler is superior in a lot of cases, however only by a small...

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

...t. I only insert perdicates for the conditional branch implementation. But I don't think they are that important. A divergent branch(inside one warp) is more or less the same. Still it would be nice to have them and investicate the integration into LLVM. [Villmow, Micah] From looking at the llvmptxbackend, it does not fully support vector types. This in my perspective is one of the greatest benefits of the backend code-generator, automatic support for vector types in LLVM-IR that are not natively supported by the target machine via vector splitting. You are right, my backend only supports vector ty...

...e >> representation, etc. in the target-specific codegen)? >> >> I've have been wanting to see predicates (vector and scalar) in the >> LLVM IR for a long time.  Perhaps the PTX backend is an opportunity >> to explore that. > [Villmow, Micah] From looking at the llvmptxbackend, it does not fully support vector types. > This in my perspective is one of the greatest benefits of the backend code-generator, automatic support > for vector types in LLVM-IR that are not natively supported by the target machine via vector splitting. >> >>                      ...

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

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

On Aug 10, 2010, at 12:05 PM, David A. Greene wrote: >> >> The PTXBackend probably needs more test cases. I'm currently covering a >> lot of LLVM and PTX features but the test suite is still not exhaustive. >> I took the coding standards into account and the license is now >> compatible to LLVM. I don't know what else needs to be done? > > Checking

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

On Tue, May 17, 2011 at 2:52 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On May 17, 2011, at 11:32 AM, Andrew Clinton wrote: > > > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote: > >> What you can do instead is: > >> > >> 1) Just use virtual registers and skip register allocation, or > >> > >> 2) Allocate to a

On May 17, 2011, at 11:32 AM, Andrew Clinton wrote: > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote: >> What you can do instead is: >> >> 1) Just use virtual registers and skip register allocation, or >> >> 2) Allocate to a small register file, implement memory operand folding, and pretend that spill slots are registers. >> >> /jakob >>

Helge Rhodin <helge.rhodin at alice-dsl.net> writes: >> But I didn't study their code thoroughly, so I might be wrong about this. >> > Yes, we don't use the target-independent code generator and the > backend is based on the CBackend. We decided to not use the code > generator because PTX code is also an intermediate language. The > graphics driver