[LLVMdev] PTX backend, BSD license
helge.rhodin at alice-dsl.net
Tue Aug 10 04:15:45 PDT 2010
>>> 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.
>> How does this relate, at all, to the backend here:
>> 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 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.
> 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.
We already support most of the PTX instruction set. Texture lookup,
structs&arrays, function calls, vector types,
different address spaces and many intrinsics. Not all intrinsics are
implemented yet because they are not required
by our application, but it is easy to add them. Only the fused
operations(e.g. MAD) are not supported and it will
probably be not as easy as in the target independent code generator. But
it might be that they are also inserted by
the graphics driver compiler. I'm not sure about that, but I remember
seeing it once(Indeed it would make sense to
do that during instruction selection). Too bad that NVIDIA does not
release any detailed information on their
> How does this relate, at all, to the backend here:
> 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. :)
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?
More information about the llvm-dev