[LLVMdev] GSoC proposal: TGSI compiler back-end.

[Francisco Jerez]

Although I'm sending this as a GSoC proposal, I'm well aware that the
amount of work that a project of this kind involves largely exceeds the
scope of the GSoC program.  I think that's okay: my work here wouldn't
be finished at the end of this summer by any means, it would merely be a
start.

TGSI is the intermediate representation that all open-source GPU drivers
using the Gallium3D architecture understand.  Until now it's mainly been
used for graphics (vertex and fragment shaders and such), but doing
general-purpose computing with it is possible in principle (actually,
necessary for GL4), and it's been the object of a number of extensions
and improvements during the last couple of years to make it more
suitable for that purpose.

The objective of the project would be to set a basis for a compiler
back-end targeting the TGSI language.

The first to be benefited from such a back-end would be the Nouveau nv50
and nve4 drivers, that would get OpenCL support easily without much
additional work, other Gallium drivers will also benefit from it as they
implement the missing language and API bits.

I think a reasonable objective for this summer would be to be able to
generate correct TGSI code for a decent subset of the CL tests from the
piglit suite [1].  In any case I believe that it would be more important
to concentrate on writing a clean code base (that would be likely to be
reviewed by others and accepted into mainline in the future) and
addressing the main design challenges (ideally with the broadest
possible consensus from the community and the least possible quantity of
target-specific band-aids working around limitations of the common
infrastructure) than to concentrate on feature completeness.

Among the issues that have to be addressed is the fact that TGSI is a
stack-less architecture (though it seems that some register-based
calling convention could be used and some sort of emulated stack could
be used for the program's automatic storage), the fact that the language
has only limited (if any) support for unstructured control flow
(apparently 'Target/R600/AMDGPUStructurizeCFG.cpp' could be helpful if
we turned it into a generic transform pass, but I'm not convinced it's
the best choice yet), the fact that the language cannot represent any
arithmetic or memory access with a word width of less than 32 bits
(though that seems less of an issue...), and the fact that the MC layer
doesn't seem to fit the object format that Gallium expects right now
especially well.

Looking forward to your feedback.

[1] http://cgit.freedesktop.org/piglit 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130404/220e8065/attachment.sig>