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

[罗勇刚(Yonggang Luo)]

I feels SPIR-V doesn't like to be a backend, cause it's can be
translate to different target(Such as NPTX and R600 or other GPU)
But SPIR-V is not llvm IR, cause SPIR-V is have something llvm-ir
doesn't have and removed something from llvm-ir.

So I think SPIR-V is another IR that seat between the clang-frontend
and llvm-IR.
Like C# IR or Java ByteCodes does.
So clang -> SPIR-V -> LLVM-IR -> Backends.
So

                     C# MSIL
Front End-      Java Byte Codes               LLVM-IR                 Backends.
                    SPIR-V
                     Other Byte-Codes

2015-05-18 1:54 GMT+08:00 Aleksey Bader <aleksey.bader at mail.ru>:
> 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



-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo