search for: ptxbackend

Hi everyone, I downloaded the latest version of LLVM PTX backend from http://www.prog.uni-saarland.de/projects/anysl and made the required changes to all the files mentioned in the README. But I get the following error when I compile it. llvm[3]: Compiling PTXBackend.cpp for Release build In file included from PTXBackend.h:70:0, from PTXBackend.cpp:36: PTXPasses.h: In constructor ‘PTXBackendInsertSpecialInstructions::PTXBackendInsertSpecialInstructions(std::map<const llvm::Value*, const llvm::Value*>&)’: PTXPasses.h:93:63: error: no m...

Hey everybody, good news for everyone interested in the PTX backend: We decided to release the current source code under the GPL - you can find the latest tarball here: http://www.prog.uni-saarland.de/projects/anysl You will find the README in the attachment, which should hopefully answer a lot of questions concerning the implementation and the current status. If you have further questions,

...ler which compiles PTX code to machine > code targeting a particular GPU architecture. It performs register > allocation, instruction scheduling, dead-code elimination, and other > late optimizations. Thus we don't need most of the target-independent > code generator features in the PTXBackend. Some of these could still be useful to aid the NVIDIA compiler. But I don't have any hard data to support that assertion. :) > We already support most of the PTX instruction set. Texture lookup, > structs&arrays, function calls, vector types, different address spaces > and man...

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

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

Hi, Chris Lattner wrote: > 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...

...de to > machine > > code targeting a particular GPU architecture. It performs register > > allocation, instruction scheduling, dead-code elimination, and other > > late optimizations. Thus we don't need most of the target-independent > > code generator features in the PTXBackend. > > Some of these could still be useful to aid the NVIDIA compiler. But I > don't have any hard data to support that assertion. :) [Villmow, Micah] For the AMD backend that I work on, having these turned on are invaluable. If the NVIDIA compiler is anything like the ATI graphics co...

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

...gt; > > code targeting a particular GPU architecture. It performs register > > > allocation, instruction scheduling, dead-code elimination, and > > > other late optimizations. Thus we don't need most of the > > > target-independent code generator features in the PTXBackend. > > > > Some of these could still be useful to aid the NVIDIA compiler. > > But I don't have any hard data to support that assertion. :) > [Villmow, Micah] For the AMD backend that I work on, having these > turned on are invaluable. If the NVIDIA compiler is anything...