Thank Nick for kindly reviewing the patch. Here is the link to the
source code of the PTX backend; it would help Nick review the patch.
The source code from above link is a working prototype. So it will
not be upstreamed as is; I will refactor and add unimplemented
features while upstreaming it. That said, the source code from above
* is not guarantee to be compilable on other machines,
* is not stable or bug-free, and
* should not be considered as the final version for upstream.
I decided to take the code generator approach (referred to as codegen
approach) rather than C backend appraoch (referred to as cbe approach)
for the following reasons (in fact, I had my first prototype in cbe
approach, but later I abandoned it and rewrote in codegen approach).
This would partly answer previous questions about comparison between
* LLVM should not rely on nVidia's design of its CUDA toolchain. To
my knowledge, nVidia does not make any commitment on how much
optimization would be implemented in its graphics driver compiler. A
backend with few optimization supports would screw up if nVidia
decides move most of optimizer to its CUDA compiler from its graphics
* nVidia's CUDA compiler has a non-trivial optimizer; this should
suggest that late optimization alone is not sufficient. If LLVM's PTX
backend is trying to provide a comparable alternative to nVidia's CUDA
compiler, the backend should have a good code optimizer. In my
experiment, the prototype PTX backend generates better optimized code
than nVidia's CUDA compiler in some cases.
* PTX is a virtual instruction set that is not designed for an
optimizer; for one, it is even not in SSA form. So graphics driver
compiler's optimizer might not do its job very well, and I would
suggest we should not rely on its optimization.
* The codegen approach is actually simpler than the cbe approach. PTX
is mostly RISC-based; that said, the codegen approach leverages from
most of *.td and from implementations of existing matured RISC
backends such as ARM, PowerPC, and Sparc. Besides, I guess most
developers would be more familiar with *.td than C backend. In fact,
it only took me two weeks to write a working prototype from scratch --
and I had had no any prior experience on LLVM's codegen.
* So far my backend is less complete than other backends based on cbe
approach, but considering the simplicity of codegen approach, a
backend based on codegen approach should catch up with them in short
* Masked operation, as well as branch folding and alike, is much
easier to implement in codegen approach. I am not sure how much
performance improvement could be achieved from these optimizations,
but it is worth trying.
All in all, I would propose a PTX backend in codegen approach after I
have implemented both.