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

[Liu, Yaxun (Sam)]

I have no objection to llvm/lib/SPIRV if the community recommends it.

For OpenCL types and builtin functions, the converter currently assumes the LLVM bitcode follows the SPIR 1.2/2.0 metadata format and IA64 name mangling scheme. I see the benefits of using intrinsics to represent OpenCL builtin functions, but we need to sort out some implementation details and the potential impact on OpenCL builtin library.

Sam

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Aleksey Bader
Sent: Sunday, May 17, 2015 1:55 PM
To: Reid Kleckner
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

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?
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev