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

[Nicholas Wilson via llvm-dev]

> On 31 Jul 2017, at 3:23 pm, Neil Henning <llvm at duskborn.com> wrote:
> 
> Yup to a third backend sorry ;)
> 
> We want a backend in tip LLVM - but I think approaching this from OpenCL SPIR-V's perspective (whereby almost everything in LLVM is 1:1 implementable in OpenCL SPIR-V) will cause a headache when adding Vulkan SPIR-V's more strict requirements.

I’m not approaching this from OpenCL’s perspective so much as approaching it from LLVM’s perspective. i.e. I want a solution that 
* removes the dependance on Itanium mangled C++ (windows support. Also I don't care for C++, I am developing for a different front end)
* will be acceptable by the LLVM folks (so I don't have to maintain it by myself).

to that end I’m using tablegen and intrinsics, although I’m busy with other things at the moment (if you think you would get use from them, please feel free to use the `.td`s). But I feel that approach is not at odds with getting something that works well for Vulkan, consider that the other backends are also not much more than a bunch of IR passes.
Other than restrictions on pointers and associated aliasing, and some additional loop requirements (OpLoopMerge and reducibility) what other restrictions does Vulkan have? I’ve only done a cursory glance over the non instruction parts of the spec.

> The vulkan GLSL extended instructions are here - https://www.khronos.org/registry/spir-v/specs/1.0/GLSL.std.450.html

Thanks, they look much less convoluted than OpenCL’s.

> An example of where we'd need significant changes to support Vulkan https://github.com/google/clspv/blob/master/lib/ReplacePointerBitcastPass.cpp (Vulkan SPIR-V does not allow pointer bitcasts at all - we needed to transform any code that used this pattern into a load as the original type and then bitcast the value instead). I am not a backend person - it'd be useful to me if anyone who is a backend person could tell me if the type legalization could handle this in a 'real' backend?

Sorry I’m not a backend person either.

Moving forward, other than securing the triples spirv32, spirv64, and spirvlogical from LLVM, how can we go about coordinating efforts? I feel that having one backend is a better use of everybody’s time than having three. If we don't get around to anything I’m sure we can organise something at IWOCL.

Nic

(Sorry forgot to hit reply all last time)