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

Tomeu Vizoso via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 9 01:36:32 PST 2018

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:

>> 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

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



More information about the llvm-dev mailing list