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

[Francisco Jerez]

Tom Stellard <tom at stellard.net> writes:
>[...]
>> >> 
>> >>   * Get object file generation working.
>> >>     (approx. June 17 - July 8)
>> >> 
>> >>     The output format will be the one expected by Mesa. The
>> >>     implementation will take advantage of the existing MC assembler
>> >>     API as much as possible.
>> >>
>> >
>> > Can you elaborate a little more on the output format you will be using?
>> > For example, will you be generating ELF binaries with special metadata
>> > sections (This is what R600 currently does) or will you be creating your
>> > own object format.
>> 
>> I'd be fine with using ELF, but it would definitely need special
>> metadata sections as you say (for kernel prototypes and so on), and
>> clover would have to be fixed to deal with it correctly -- OTOH the
>> minimalistic format implemented in 'clover/core/module.cpp' seems to do
>> everything we need, so another option would be to stick to it.
>>
>
> Generating ELF binaries with the LLVM API is really easy to do and you
> can use R600 as a minimalistic example.  Also, keep in mind that OpenCL
> 1.2 has API calls for linking kernel objects so that is something that
> will need to be supported.  I'm not sure if it will be easier to do
> linking with ELF or with a custom format, but that's something you
> should look into.
>
Yeah, I think you're right, ELF is probably our best bet with a view to
OpenCL 1.2.  I've fixed my proposal.

>[...]
>> 
>> >> 
>> >>   * Documentation and remaining clean-up work.
>> >>     (approx. September 16 - September 23)
>> >>
>> >
>> > I think your proposal should also include a plan for getting the backend
>> > into mainline LLVM, because this is really the ultimate goal of the
>> > project.  Your plan should include where the code repository will be
>> > stored and how you will engage with the community to help you review
>> > the code.  I think this is really important no just for you, but also
>> > for the LLVM community to know what they need to do as far as helping
>> > get the backend into the main tree.
>> >
>> I'm a little lost on this point...  My plan is just to keep working on
>> it until it's good enough to be considered suitable for mainline,
>> meanwhile it could live in a separate repository in freedesktop or
>> github.  Not sure what else would be expected from me -- of course, I'm
>> willing to keep fixing bugs, API breakages and reviewing related patches
>> once it's merged to mainline.
>> 
>
> Basically what I'm trying to say is that I think the goal should be to
> merge the backend by the end of the summer.  It is difficult to get
> new backends accepted into the main tree mostly due to the fact that
> the core developers don't usually have much spare time to do reviews.
> I think if you put off trying to merge the code until after the summer,
> the backend may fall off the radar of the LLVM developers, and it will
> be even harder to get someone to look at it.
>

OK, I've rephrased the project objective slighly to make that point a
bit clearer.

Thank you, a revised proposal follows.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: llvm-tgsi-backend-proposal.text
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130424/1a1d2cfb/attachment.text>
-------------- 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/20130424/1a1d2cfb/attachment.sig>