[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

[Aleksey Bader]

On Fri, May 15, 2015 at 10:53 PM, Reid Kleckner <rnk at google.com> wrote:
> I want to point out that being stable across LLVM versions means that LLVM
> will be able to express things that SPIRV cannot. Any new IR feature we add
> to LLVM may not be expressable in SPIRV. EH landingpads, for example, are
> probably not supported by SPIRV and must be stripped or rejected.
>
> So, the process of writing SPIRV will strip, lower, or reject some LLVM IR
> bits. However, roundtripping IR through SPIRV should probably be idempotent.
> The first translation will change the program, but repeating the roundtrip
> should produce the same IR and SPIRV from then on. If that's achievable,
> then I agree, this is definitely a serialization format and not something
> lower-level (x86) or higher-level (C).

I'd like to add that SPIR-V also defines data types and operations
which have no native representation in LLVM IR. For instance, Clang
generates opaque structure type to represent OpenCL C image types. It
might be defined differently by Vulkan compiler, OpenCL C++ compiler
or some other LLVM-based compiler front-end.

The same is true for the extended instruction set: e.g. SPIR-V has sin
instruction intended to represent 'sin' built-in function, which is
implemented in LLVM IR as a function call:

call float _Z3sinf (float ) ;OpenCL C or GLSL - sin must be overloadable.
call float _ZN2cl3sinEf (float ) ; OpenCL C++ - 'sin' must be in cl namespace.
call float sinf (float ) ; some C-like language that do not require
function overloading

So we will either need some adapters that will prepare LLVM IR for
SPIR-V serialization or define 'standard' LLVM IR constructs to
represent SPIR-V types and operations, which compiler front-ends will
generate.
Does it make sense to utilize LLVM intrinsics for SPIR-V extended instructions?