[LLVMdev] PTX backend, BSD license

[Villmow, Micah]

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Helge Rhodin
> Sent: Sunday, August 15, 2010 3:40 PM
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] PTX backend, BSD license
> 
> 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
[Villmow, Micah] I think having multiple backends make learning easier and this would allow 
some experimentation that other backends do not. However, I do not believe that it will
be able to handle as broad a range of inputs like a target-independent backend could.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev