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

[Francisco Jerez]

Francisco Jerez <currojerez at riseup.net> writes:

> 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 

Pity not to see any interest in this since I brought up the idea two
weeks ago.  I've uploaded a first attempt at writing a TGSI back-end
here [2].  It's able to generate code -- though only in assembly form
and with many loose ends still.

Also, would it be possible for Tom Stellard (CC'ed) to mentor me?  He's
been working on the R600 back-end (which is similar in purpose and
limitations) and the Mesa/Gallium3D project so he might be the right
person?

If it's OK I'll be preparing a more formal proposal during the next few
days.

[2] https://github.com/curro/llvm/commit/a1aad41463c36220f2c5b03645843f39e6bf1b9d
-------------- 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/20130422/4efdff01/attachment.sig>