[llvm-dev] [SPIR-V] SPIR-V in LLVM

[Tomeu Vizoso via llvm-dev]

On 28 September 2017 at 00:52, Nicholas Wilson via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>> On 27 Sep 2017, at 8:21 pm, Tomeu Vizoso <tomeu.vizoso at collabora.com> wrote:
>>
>> Hi there,
>>
>> any news on coordination? We have customers who are successfully using
>> Mesa in their products, and that are now asking about OpenCL.
>
> None yet, I’m still waiting for IWOCL to spearhead the coordination.
>
>> My current impression is that easiest would be to do what Tom suggested
>> before, and only re-evaluate inclusion in LLVM proper once things are
>> more mature.
>>
>> One path for me would be to take Khronos' or Nic's work and convert it
>> into something that can be packaged by Linux distributions (so it needs
>> to work with the latest LLVM release, with no patches).
>
> Mine works with LLVM trunk at the moment.
> I think all it would take would be to roll back the fixes to make and add it to the build system to make it work with 5.0.
> The code generator is a regular (well for the purposes of a front end developer) backend so should be very easy to integrate. It does lack an OpenCL C front end though, you would need to forward port Khronos’ one.

Finally took some time to find out how hard would be to put Khronos'
LLVM-SPIRV into a shape that could be used by Mesa, and it didn't turn
that bad: https://gitlab.collabora.com/tomeu/llvm-spirv

I basically took Khronos' master branch, rewrote history to remove
anything not SPIRV-specific, and applied on top Nic's changes to match
LLVM 6.0. Also borrowed some build system changes from clspv.

>> Another path would be to extend clspv to cover the whole of OpenCL, but
>> I don't know if Codeplay/Google are interested in taking such patches.

Doesn't look like that would be the case:
https://github.com/google/clspv/issues/63

>> Is here interest in coordinating efforts?
>>
>> Regards,
>>
>> Tomeu
>
> Definitely although I’m a bit busy at the moment. I hope you can make it to IWOCL.

Will look at being there. For the moment I'm going to count on using
this fork as a starting point so I can start my work on
Mesa/Clover/Freedreno.

Everybody else is welcome to contribute changes towards making it
suitable for inclusion in LLVM, but I need it to not regress in the
meantime.

Regards,

Tomeu