On Fri, May 15, 2015 at 11:50 AM, David Chisnall < David.Chisnall at cl.cam.ac.uk> wrote:> On 15 May 2015, at 17:53, Chris Bieneman <beanz at apple.com> wrote: > > > > +1 to lib/Target/SPIRV/(Reader|Writer) > > > > I really like this idea. I’ve talked with some people on both the LLVM > and Khronos sides and I really think adding SPIR-V support to LLVM as an > optional program serialization format would be fantastic. I think it would > make it even easier for LLVM-based tools to be integrated into GPU > authoring and execution pipelines. > > Agreed. Unlike HSAIL, SPIR-V looks like a very sane design and having an > in-tree serialisation format that’s stable across LLVM versions is likely > to make SPIR-V useful for a number of things outside of its initial scope. >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). Sounds useful. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150515/940fe2b9/attachment.html>
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?
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
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