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 contains a compiler 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 many intrinsics.Do you generate masked operations? If so, are you managing masks/predicates with your own target-specific representation _a_la_ the current ARM backend?>> 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 don't know much about the target-independent code generator but I > think we use distinct approaches which cannot > be merged in a reasonable way. Probably both approaches have their own > pros and cons.Certainly.>> Is there work to upstream this? I've got a relatively unused NVIDIA >> card at home. :) >> >> -Dave >> > 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 it in. :) Really, we probably should do some sort of code review, but Chris would have to indicate what he wants. -Dave
> -----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:05 PM > To: Helge Rhodin > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] PTX backend, BSD license > > 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 contains a compiler 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. :)[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 compiler, it is written for speed and assumes smaller graphics kernels, but with more generic compute kernels, doing some preliminary optimizations/scheduling/allocation helps generate better code.> > > We already support most of the PTX instruction set. Texture lookup, > > structs&arrays, function calls, vector types, different address > spaces > > and many intrinsics. > > Do you generate masked operations? If so, are you managing > masks/predicates with your own target-specific representation _a_la_ > the > current ARM backend? > > >> 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 don't know much about the target-independent code generator but I > > think we use distinct approaches which cannot > > be merged in a reasonable way. Probably both approaches have their > own > > pros and cons. > > Certainly. > > >> Is there work to upstream this? I've got a relatively unused NVIDIA > >> card at home. :) > >> > >> -Dave > >> > > 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 it in. :) Really, we probably should do some sort of code > review, but Chris would have to indicate what he wants. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Tue, 10 Aug 2010 14:21:43 -0500 "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:05 PM > > To: Helge Rhodin > > Cc: llvmdev at cs.uiuc.edu > > Subject: Re: [LLVMdev] PTX backend, BSD license > > > > 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 contains a compiler 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. :)> [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 compiler, it is written for speed and assumes smaller > graphics kernels, but with more generic compute kernels, doing some > preliminary optimizations/scheduling/allocation helps generate better > code.I think AMD's stream SDK uses LLVM already, at least I've seen some llc invocations and some amdil backend. I don't know if it compiles down to GPU instructions or just to some IL which is then compiled again. Unfortunately its not open source, and it only works with fglrx, not Mesa so I stopped looking further. http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=120683&%20enterthread=y Best regards, --Edwin
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 it in. :) Really, we probably should do some sort of code > review, but Chris would have to indicate what he wants.It needs to be code reviewed. Please split it into reasonable sized chunks and get them reviewed. -Chris
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 done? >>> >> Checking it in. :) Really, we probably should do some sort of code >> review, but Chris would have to indicate what he wants. >> > > It needs to be code reviewed. Please split it into reasonable sized chunks and get them reviewed. > > -Chris >Are there any volunteers out there? :) Thanks! David A. Greene wrote:> > Do you generate masked operations? If so, are you managing > masks/predicates with your own target-specific representation _a_la_ the > current ARM backend? >No, currently not. 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 types for load, store, texture fetches and extract element instructions(every vector instructions PTX supports). Nothing like vector splitting is done. Villmow, Micah wrote:>>> 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 contains a compiler 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. :) >> > [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 compiler, it is written for speed and assumes smaller graphics kernels, but with more generic compute kernels, doing some preliminary optimizations/scheduling/allocation helps generate better code.I agree with you that the target-independent code generator approach has some benefits(vector splitting, may be late-optimizations..) in comparison to my implementation. But it I think my approach is the simpler one (at least in the short run) and it is further progressed. What do you think, does it make sense to put more work into my backend(code review..)? The backend already gives us the opportunity to develope and test new GPU related optimizations and improve LLVM(predicates) and Clang(address spaces). From my point of view the higher level optimizations, like choosing the "right" address space, are more intresting and profitable. Such optimizations are not dependent on the backend implementation and could seamlessly be used with the new ptx backend once it is finished. --Helge