[LLVMdev] PTX backend, BSD license

David A. Greene greened at obbligato.org
Tue Aug 10 12:05:11 PDT 2010

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.


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


More information about the llvm-dev mailing list