[RFC] Upstreaming LLVM/SPIR-V converter

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Neil Henning
The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V'. There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable), and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).

I think what Sean suggested of having a very thin backend that satisfies what a user will want when producing SPIR-V + setting up the target specific intrinsics, and then the majority of the actual SPIR-V production code being in lib/SPIRV sounds like a good approach to me!

Cheers,
-Neil.

On 19/05/15 00:24, Owen Anderson wrote:

On May 18, 2015, at 2:09 PM, Sean Silva <[hidden email]> wrote:

From an end-user's perspective it sounds like the use case for SPIR-V though is a lot more similar to a target though. E.g. the user is notionally telling clang "target SPIR-V" (including doing any IR optimizations, any special "codegenprepare" special passes, etc.), rather than "act like you're targeting X, but -emit-llvm/-emit-spirv instead" (which is what I imagine from a component purely in lib/SPIRV).


SPIR-V is a serialization format between the user’s frontend and the vendor’s backend.  From the user’s perspective, it looks like a target.  From the vendor’s perspective, it looks like a frontend.  In this sense, it is very comparable to LLVM bitcode itself.

—Owen


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Pierre-Andre Saulais-2
Indeed, SPIR-V not being a target would prevent using clang to generate SPIR-V (which target triple would be used?) On the other hand, maybe it would be possible to have a clang target without a corresponding LLVM target. I'm not familiar with the target machinery in clang so I don't know if it would work or not.

Either way, I don't think any LLVM tool should output SPIR-V directly, except maybe a simple conversion tool between the two IRs.

Pierre-Andre

On 19/05/15 09:25, Neil Henning wrote:
The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V'. There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable), and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).

I think what Sean suggested of having a very thin backend that satisfies what a user will want when producing SPIR-V + setting up the target specific intrinsics, and then the majority of the actual SPIR-V production code being in lib/SPIRV sounds like a good approach to me!

Cheers,
-Neil.

On 19/05/15 00:24, Owen Anderson wrote:

On May 18, 2015, at 2:09 PM, Sean Silva <[hidden email]> wrote:

From an end-user's perspective it sounds like the use case for SPIR-V though is a lot more similar to a target though. E.g. the user is notionally telling clang "target SPIR-V" (including doing any IR optimizations, any special "codegenprepare" special passes, etc.), rather than "act like you're targeting X, but -emit-llvm/-emit-spirv instead" (which is what I imagine from a component purely in lib/SPIRV).


SPIR-V is a serialization format between the user’s frontend and the vendor’s backend.  From the user’s perspective, it looks like a target.  From the vendor’s perspective, it looks like a frontend.  In this sense, it is very comparable to LLVM bitcode itself.

—Owen


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Owen Anderson-2
In reply to this post by Neil Henning

> On May 19, 2015, at 1:25 AM, Neil Henning <[hidden email]> wrote:
>
> The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V’.

The *entire point* of my email was that that is only one of two use cases of SPIR-V.  As I said above, it’s a serialization format between a frontend and a backend, which means that for some clients it is an output format and for others it’s an input format.  It’s also likely that SPIR-V to SPIR-V translators will exist in the future.

> There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable),

Why does that motivate it being a target?  Intrinsics do not have to be linked to a target.

> and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).

Again, why does that motivate it being a target?  No amount of legalization can define away fundamentally unsupported major constructs.

More generally,  making it a target immediately invokes a lot of behavior that is undesirable for a serialization format between a fronted and a backend.  You don’t *want* LLVM to do a lot of wacky CodeGenPrepare and/or lowering before emitting SPIR-V, which is likely to lose source-level information that the eventual consumer wanted to have available.  You do not want to leverage any of the general target architecture.

I really don’t see any strong reason for it to be a target at all, and all the use cases I can see for it are exactly the same as the use cases for LLVM bitcode, with a  “for graphics” qualifier tacked on.

—Owen



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Stefanus Du Toit
On Tue, 19 May 2015 at 11:34 Owen Anderson <[hidden email]> wrote:
More generally,  making it a target immediately invokes a lot of behavior that is undesirable for a serialization format between a fronted and a backend.  You don’t *want* LLVM to do a lot of wacky CodeGenPrepare and/or lowering before emitting SPIR-V, which is likely to lose source-level information that the eventual consumer wanted to have available.  You do not want to leverage any of the general target architecture.

I don't think the suggestion is to use SelectionDAG and friends in this target. My understanding is that this would only involve registering as a target similar to the way the CppBackend does, then invoking the code from lib/SPIRV.

By registering as a target you can select SPIR-V for Clang emission the same way you select, say, X86 or ARM, rather than adding a special flag.

Stefanus

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Eric Christopher
In reply to this post by Owen Anderson-2
I agree with Owen here, this is really just a serialization of llvm IR that may or may not support various LLVM IR features. Can you give another example of something not legal in SPIR that is legal in LLVM IR that you'd still be able to/want to lower?

(Bonus points, a serialization option that includes new LLVM IR features under a "next version" of SPIR :)

-eric

On Tue, May 19, 2015 at 8:35 AM Owen Anderson <[hidden email]> wrote:

> On May 19, 2015, at 1:25 AM, Neil Henning <[hidden email]> wrote:
>
> The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V’.

The *entire point* of my email was that that is only one of two use cases of SPIR-V.  As I said above, it’s a serialization format between a frontend and a backend, which means that for some clients it is an output format and for others it’s an input format.  It’s also likely that SPIR-V to SPIR-V translators will exist in the future.

> There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable),

Why does that motivate it being a target?  Intrinsics do not have to be linked to a target.

> and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).

Again, why does that motivate it being a target?  No amount of legalization can define away fundamentally unsupported major constructs.

More generally,  making it a target immediately invokes a lot of behavior that is undesirable for a serialization format between a fronted and a backend.  You don’t *want* LLVM to do a lot of wacky CodeGenPrepare and/or lowering before emitting SPIR-V, which is likely to lose source-level information that the eventual consumer wanted to have available.  You do not want to leverage any of the general target architecture.

I really don’t see any strong reason for it to be a target at all, and all the use cases I can see for it are exactly the same as the use cases for LLVM bitcode, with a  “for graphics” qualifier tacked on.

—Owen



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

JinGu Kang-2
>By registering as a target you can select SPIR-V for Clang emission the same way you select, say, X86 or ARM, rather than adding a special flag.

How do you think about Combination of Backend_EmitSPIRV Action,
createSPIRVWritePass and -emit-spirv command line option on clang?
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Chris Lattner-2
In reply to this post by Neil Henning

> On May 19, 2015, at 1:25 AM, Neil Henning <[hidden email]> wrote:
>
> The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V'. There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable), and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).
>
> I think what Sean suggested of having a very thin backend that satisfies what a user will want when producing SPIR-V + setting up the target specific intrinsics, and then the majority of the actual SPIR-V production code being in lib/SPIRV sounds like a good approach to me!

There are two different things going on here:

1) Where the code lives in the llvm tree.
2) How clang and other tools expose it to users.

Per #1, it is pretty clear to me that this is a serialization format and should be structured like the bitcode reader & writer.  It is not a target, though maybe it also need a minimal target (but not instruction selection tables etc) so that clang and other tools can generate code for it.

Per #2, that is a discussion for the clang lists.

-Chris


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Neil Henning
In reply to this post by Owen Anderson-2
Answers to Owen;
>> There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable),
> Why does that motivate it being a target?  Intrinsics do not have to be linked to a target.
My motivation here is that a target would give us a nice logical
separation - EG. these intrinsics only work with the SPIR-V target and
there is no way you should be calling them from any other context. I
really didn't think people would want us to add a bunch of intrinsics to
Intrinsics.td.
>> and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).
> Again, why does that motivate it being a target?  No amount of legalization can define away fundamentally unsupported major constructs.
>
> More generally,  making it a target immediately invokes a lot of behavior that is undesirable for a serialization format between a fronted and a backend.  You don’t *want* LLVM to do a lot of wacky CodeGenPrepare and/or lowering before emitting SPIR-V, which is likely to lose source-level information that the eventual consumer wanted to have available.  You do not want to leverage any of the general target architecture.
>
> I really don’t see any strong reason for it to be a target at all, and all the use cases I can see for it are exactly the same as the use cases for LLVM bitcode, with a  “for graphics” qualifier tacked on.
My idea was that this would be backend ala the CppBackend, it would
essentially just be a ModulePass that calls the lib/SPIRV/*Writer.cpp
code. The 'backend' in this context is purely so that we can then enable
Clang to target SPIR-V in the same consistent manner to all the other
targets it supports.

As Chris said;

> There are two different things going on here:
>
> 1) Where the code lives in the llvm tree.
> 2) How clang and other tools expose it to users.
>
> Per #1, it is pretty clear to me that this is a serialization format and should be structured like the bitcode reader & writer.  It is not a target, though maybe it also need a minimal target (but not instruction selection tables etc) so that clang and other tools can generate code for it.

Is exactly what I thought we'd end up with.

-Neil.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

罗勇刚(Yonggang Luo)
In reply to this post by Chris Lattner-2
2015-05-20 0:29 GMT+08:00 Chris Lattner <[hidden email]>:

>
>> On May 19, 2015, at 1:25 AM, Neil Henning <[hidden email]> wrote:
>>
>> The problem is - as Sean and Pete (and others before) have pointed out, from a users perspective they'll want to say 'clang make me SPIR-V'. There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable), and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).
>>
>> I think what Sean suggested of having a very thin backend that satisfies what a user will want when producing SPIR-V + setting up the target specific intrinsics, and then the majority of the actual SPIR-V production code being in lib/SPIRV sounds like a good approach to me!
>
> There are two different things going on here:
>
> 1) Where the code lives in the llvm tree.
> 2) How clang and other tools expose it to users.
>
> Per #1, it is pretty clear to me that this is a serialization format and should be structured like the bitcode reader & writer.  It is not a target, though maybe it also need a minimal target (but not instruction selection tables etc) so that clang and other tools can generate code for it.
>
> Per #2, that is a discussion for the clang lists.
>
From my points of view, there is two different of roles along with SPIR-V.
1, As a backend of clang, in this way, maybe we treat SPIR-V as a llvm
backend is the easiest way to implement, but that not agree with the
nature of SPIR-V, it's a IR(intermediate representation) , and Target
means the machine level abstraction. Anyway, we also have Asm.js and
CppBackend have same feature.
2, As a frontend IR, it's would first translate to LLVM IR, and then
translate to Target Machine.

So maybe we need to have two different kinds of target,
One is real target like x86, x64, arm and so on.

The other one is CppBackend, Asm.js SPIR-V, and maybe Java ByteCodes MSIL

> -Chris
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
         此致

罗勇刚
Yours
    sincerely,
Yonggang Luo

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

David Chisnall-5
On 19 May 2015, at 12:40, 罗勇刚(Yonggang Luo) <[hidden email]> wrote:
>
> From my points of view, there is two different of roles along with SPIR-V.
> 1, As a backend of clang, in this way, maybe we treat SPIR-V as a llvm
> backend is the easiest way to implement, but that not agree with the
> nature of SPIR-V, it's a IR(intermediate representation) , and Target
> means the machine level abstraction. Anyway, we also have Asm.js and
> CppBackend have same feature.

I think that this should be generalised.  It’s not just clang that is likely to be generating SPIR-V - other DSL compilers that want to run code on the GPU are likely to as well, along with existing things (I wouldn’t be surprised to see Julia generate SPIR-V, for example).

There are therefore two questions:

- How will clang expose this to users (cfe-dev question)?
- How will SPIR generation be exposed to front-end developers in general?

> 2, As a frontend IR, it's would first translate to LLVM IR, and then
> translate to Target Machine.

There may also be a third case of things that both consume and produce SPIR-V.  Things that are the moral equivalent of linkers may fit in this, as may code obfuscation tools, and more traditional optimisers.

David


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Sean Silva-2
In reply to this post by Neil Henning


On Tue, May 19, 2015 at 9:48 AM, Neil Henning <[hidden email]> wrote:
Answers to Owen;
There are things in SPIR-V that are not representable by the LLVM IR, so we'd have to add SPIR-V specific intrinsics for this (again making the case for having it as a target more palatable),
Why does that motivate it being a target?  Intrinsics do not have to be linked to a target.
My motivation here is that a target would give us a nice logical separation - EG. these intrinsics only work with the SPIR-V target and there is no way you should be calling them from any other context. I really didn't think people would want us to add a bunch of intrinsics to Intrinsics.td.

It actually sort of makes sense to have them somewhere more generic. If you imagine a GPU driver based on LLVM, where the flow is SPIR-V -> LLVM IR -> GPU backend, then these intrinsics actually *are* going to filter down into a backend other than a "SPIR-V backend".

So we have at least two use cases:

1)
Frontend -> LLVM IR -> SPIR-V: primary concern is for the Frontend to generate LLVM IR that contains a subset of operations suitable for SPIR-V.

2)
SPIR-V -> LLVM IR -> GPU backend: primary concern is just deserializing the darn thing. Want lib/SPIRV to just be a simple (and fast and no security vulnerabilities!) way to suck in a buffer of SPIR-V and turn it into a Module.

It seems that we're getting pretty hung up on whether something in lib/Target is necessary for various random pieces of machinery for 1). E.g. in 1) are we compiling with a "spirv triple"? (is something in lib/Target needed for this?)
In 2) we are definitely not compiling with a spirv triple (actually I wonder how that will work: when will the triple and datalayout and stuff get changed...; during the deserialization process?).

-- Sean Silva
 

and also there are things in the IR that won't be allowed when producing SPIR-V (off the top of my head, in a graphics shader with logical addressing mode a ton of pointer use is banned).
Again, why does that motivate it being a target?  No amount of legalization can define away fundamentally unsupported major constructs.

More generally,  making it a target immediately invokes a lot of behavior that is undesirable for a serialization format between a fronted and a backend.  You don’t *want* LLVM to do a lot of wacky CodeGenPrepare and/or lowering before emitting SPIR-V, which is likely to lose source-level information that the eventual consumer wanted to have available.  You do not want to leverage any of the general target architecture.

I really don’t see any strong reason for it to be a target at all, and all the use cases I can see for it are exactly the same as the use cases for LLVM bitcode, with a  “for graphics” qualifier tacked on.
My idea was that this would be backend ala the CppBackend, it would essentially just be a ModulePass that calls the lib/SPIRV/*Writer.cpp code. The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports.

As Chris said;

There are two different things going on here:

1) Where the code lives in the llvm tree.
2) How clang and other tools expose it to users.

Per #1, it is pretty clear to me that this is a serialization format and should be structured like the bitcode reader & writer.  It is not a target, though maybe it also need a minimal target (but not instruction selection tables etc) so that clang and other tools can generate code for it.

Is exactly what I thought we'd end up with.

-Neil.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Owen Anderson-2
In reply to this post by Pierre-Andre Saulais-2

On May 19, 2015, at 2:45 AM, Pierre-Andre Saulais <[hidden email]> wrote:

Indeed, SPIR-V not being a target would prevent using clang to generate SPIR-V (which target triple would be used?) 

Um, no?  See clang -emit-llvm.

—Owen

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Owen Anderson-2
In reply to this post by Neil Henning

On May 19, 2015, at 9:48 AM, Neil Henning <[hidden email]> wrote:

The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports.

This seems like a terrible reason to choose the architecture of how it’s implemented in LLVM.  The clang driver is part of the LLVM project.  If we need to add support for some kind of special SPIR-V flag akin to -emit-llvm, we can do that.  If a particular frontend vendor wants to customize the flags, they can always do so themselves.

—Owen

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Nick Lewycky-2
In reply to this post by Owen Anderson-2
On 17 May 2015 at 00:13, Owen Anderson <[hidden email]> wrote:

On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <[hidden email]> wrote:

I am thinking maybe the functionality of the bi-way conversion can be kept at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do conversions between LLVM and SPIR-V. On the other hand, we create a llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. The SPIR-V target allows Clang and other LLVM front ends to target generic OpenCL/Vulkan platforms.

I don’t think Chris was suggesting lib/Bitcode/SPIRV.  That wouldn’t make a lot of sense, since Bitcode != SPIR-V.

FWIW, I agree with Chris that it makes sense as a parallel to lib/Bitcode.  SPIR-V is (almost) an alternate encoding of LLVM IR, with a few things added/removed, and it makes sense to treat it in a similar manner to our normal serialization format.

What are the guarantees on it? Can I take .bc -> spir-V -> .bc and get identical .bc back? Can I take spir-V -> .bc -> spir-V and get identical spir-V back? If both of these are not true, in what way is it a serialization format? Or put another way, even if we call it a serialization format, it wouldn't be a serialization format of LLVM IR.

Note that even the CPPBackend is in lib/Target, and that does guarantee perfect round-trip reproduction of everything in LLVM IR, while SPIR-V afaik does not.

If it makes sense share to share code (opcode tables, etc.) between the spir-v frontend and backend, then I have no real problem putting them in a single directory. I just want it to be clear that we can continue to freely evolve LLVM IR and that there may be explicit steps to convert future LLVM IR to SPIR-V and vice versa, and a place to put that code.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Sean Silva-2
In reply to this post by Owen Anderson-2


On Tue, May 19, 2015 at 4:05 PM, Owen Anderson <[hidden email]> wrote:

On May 19, 2015, at 9:48 AM, Neil Henning <[hidden email]> wrote:

The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports.

This seems like a terrible reason to choose the architecture of how it’s implemented in LLVM.  The clang driver is part of the LLVM project.  If we need to add support for some kind of special SPIR-V flag akin to -emit-llvm, we can do that.  If a particular frontend vendor wants to customize the flags, they can always do so themselves.

What do you envision as the triple and datalayout when a frontend is compiling to SPIR-V? I'm pretty sure that a wide class of frontends for SPIR-V will literally be interested in just generating SPIR-V, with no knowledge about what the ultimate GPU target is; it is in that sense that they are "targeting" SPIR-V. That is, their frontend isn't generating $SPECIFICGPU targeted IR, and then being merely asking to have it serialized in a specific way (a la -emit-llvm); they are generating IR that is meant to be turned into SPIR-V. That is fundamentally different from -emit-llvm (on the other hand, it may not be a target; but it sure smells like one).

-- Sean Silva
 

—Owen

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Owen Anderson-2
In reply to this post by Nick Lewycky-2

On May 19, 2015, at 6:04 PM, Nick Lewycky <[hidden email]> wrote:

What are the guarantees on it? Can I take .bc -> spir-V -> .bc and get identical .bc back?

For the subset of LLVM IR that is representable in SPIR-V, I would expect this to work.  Given that SPIR-V is specialized for representing a particular kind of programming model, that seems completely reasonable to me.

Can I take spir-V -> .bc -> spir-V and get identical spir-V back?

I would expect this to work as well.

—Owen

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Owen Anderson-2
In reply to this post by Sean Silva-2

On May 19, 2015, at 7:32 PM, Sean Silva <[hidden email]> wrote:



On Tue, May 19, 2015 at 4:05 PM, Owen Anderson <[hidden email]> wrote:

On May 19, 2015, at 9:48 AM, Neil Henning <[hidden email]> wrote:

The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports.

This seems like a terrible reason to choose the architecture of how it’s implemented in LLVM.  The clang driver is part of the LLVM project.  If we need to add support for some kind of special SPIR-V flag akin to -emit-llvm, we can do that.  If a particular frontend vendor wants to customize the flags, they can always do so themselves.

What do you envision as the triple and datalayout when a frontend is compiling to SPIR-V?

I’d recommend having its own Triple.  Not that triples are *not* linked to targets in LLVM.  My understanding of SPIR-V (and a look through the documentation seems to confirm) that it doesn’t specify anything about data layouts, presumably because it needs to accommodate both many GPUs with varying ideas of what sizes and alignments should be.  If anything this pushes me even more strongly that you do *not* want to run SPIR-V-destined IR through any more of LLVM (and particularly the CodeGen infrastructure) than you have to, since a lot of that will want to bake in DataLayout knowledge.

I'm pretty sure that a wide class of frontends for SPIR-V will literally be interested in just generating SPIR-V, with no knowledge about what the ultimate GPU target is; it is in that sense that they are "targeting" SPIR-V. That is, their frontend isn't generating $SPECIFICGPU targeted IR, and then being merely asking to have it serialized in a specific way (a la -emit-llvm); they are generating IR that is meant to be turned into SPIR-V. That is fundamentally different from -emit-llvm (on the other hand, it may not be a target; but it sure smells like one).

I completely agree with you… except for the last sentence.

Honestly, the command line option aspect of this seems like a complete red herring to me.  We are talking about adding support to a data format which we will need to support both serializing IR to and deserializing IR from.  This is exactly the same as the bitcode use case, and not at all like the use case of a target.  We should structure the implementation according to the ways it will actually be used; rewiring a clang driver command line flag to “make it look pretty” is the most trivial part of the entire process.

—Owen


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Neil Henning
On 20/05/15 08:37, Owen Anderson wrote:

On May 19, 2015, at 7:32 PM, Sean Silva <[hidden email]> wrote:



On Tue, May 19, 2015 at 4:05 PM, Owen Anderson <[hidden email]> wrote:

On May 19, 2015, at 9:48 AM, Neil Henning <[hidden email]> wrote:

The 'backend' in this context is purely so that we can then enable Clang to target SPIR-V in the same consistent manner to all the other targets it supports.

This seems like a terrible reason to choose the architecture of how it’s implemented in LLVM.  The clang driver is part of the LLVM project.  If we need to add support for some kind of special SPIR-V flag akin to -emit-llvm, we can do that.  If a particular frontend vendor wants to customize the flags, they can always do so themselves.

What do you envision as the triple and datalayout when a frontend is compiling to SPIR-V?

I’d recommend having its own Triple.  Not that triples are *not* linked to targets in LLVM.  My understanding of SPIR-V (and a look through the documentation seems to confirm) that it doesn’t specify anything about data layouts, presumably because it needs to accommodate both many GPUs with varying ideas of what sizes and alignments should be.  If anything this pushes me even more strongly that you do *not* want to run SPIR-V-destined IR through any more of LLVM (and particularly the CodeGen infrastructure) than you have to, since a lot of that will want to bake in DataLayout knowledge.

At present in SPIR-V we have a decoration for alignment, so a user could decorate a type to specify a required alignment (which I would have thought in turn would become part of the data layout). Also if we are using a non-logical addressing mode the data layout would have a different pointer width specified (similar to the SPIR/SPIR64 targets in Clang at present). I'll bring it up with the SPIR group at Khronos what the expected behaviour of the alignment decoration is in this context, but at present I would say it would be legal for an LLVM module that is being turned into SPIR-V to have a user-defined data layout.

I'm pretty sure that a wide class of frontends for SPIR-V will literally be interested in just generating SPIR-V, with no knowledge about what the ultimate GPU target is; it is in that sense that they are "targeting" SPIR-V. That is, their frontend isn't generating $SPECIFICGPU targeted IR, and then being merely asking to have it serialized in a specific way (a la -emit-llvm); they are generating IR that is meant to be turned into SPIR-V. That is fundamentally different from -emit-llvm (on the other hand, it may not be a target; but it sure smells like one).

I completely agree with you… except for the last sentence.

Honestly, the command line option aspect of this seems like a complete red herring to me.  We are talking about adding support to a data format which we will need to support both serializing IR to and deserializing IR from.  This is exactly the same as the bitcode use case, and not at all like the use case of a target.  We should structure the implementation according to the ways it will actually be used; rewiring a clang driver command line flag to “make it look pretty” is the most trivial part of the entire process.

So it seems to me that we can at least agree on the location of the mainstay of the code - it should reside in lib/SPIRV and be both a reader and writer akin to the Bitcode reader/writer pair. Why don't we at Khronos work on a patch to tip LLVM that will do that, and then we can revisit how a user actually uses our code after that. We should be able to easily follow Owen's approach and see how that works out, worst case if it turns out to not work it would then be trivial to turn that into a thin backend. Seem reasonable?

Cheers,
-Neil.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Nick Lewycky-2
In reply to this post by Owen Anderson-2
On 20 May 2015 at 00:21, Owen Anderson <[hidden email]> wrote:

On May 19, 2015, at 6:04 PM, Nick Lewycky <[hidden email]> wrote:

What are the guarantees on it? Can I take .bc -> spir-V -> .bc and get identical .bc back?

For the subset of LLVM IR that is representable in SPIR-V, I would expect this to work.  Given that SPIR-V is specialized for representing a particular kind of programming model, that seems completely reasonable to me.

Can I take spir-V -> .bc -> spir-V and get identical spir-V back?

I would expect this to work as well.

I think you missed the point of my question, I am asking what LLVM promises will work, not what's "expected to work today".

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Upstreaming LLVM/SPIR-V converter

Chandler Carruth-2
In reply to this post by Yaxun Liu
Sorry for coming late to the thread, I was traveling and then quite sick, and am trying to catch up on things.

I'm generally in favor of having a SPIR-V target in upstream LLVM. There have been lots of folks on the thread that have indicated the many reasons this is advantageous. I agree with them.

However, I have a few of concerns about exactly how this is implemented that I want to bring up.

1) I don't think this should live along side lib/Bitcode. For better or worse, doing that would make it *the* LLVM stable program serialization framework, and I'm at least *very* uncomfortable with that at this stage. SPIR-V was developed by a party outside of the LLVM community, and I don't really know why we should consider it to be a viable canonical stable serialization format. I think it makes much more sense for it to be clearly *optional* (the way a "Target" in LLVM is today) and predicated on an external spec (the way a "Target" in LLVM is today). From this perspective, all of the "Target" machinery in LLVM is actually exactly right -- it can be optional, it can be omitted, and wired up to a triple, etc.

2) I think we need to be really careful about exactly what the mechanism is that it uses to serialize. I realize that the SelectionDAG is a pretty terrible fit for what SPIR-V wants to do, but skipping it has a significant problem. Currently, we have a legalization framework in the SelectionDAG. If I add a new type or a new operation to LLVM and I can generically type legalize or expand it into other operations, I don't have to update every single target (some of which I may not know anything about) to support that construct. I think it is critical to preserve this contract even with SPIR-V. Currently, this could be done easily just by abusing in a minor way the legalization facilities of SelectionDAG. I'd love it if we had a more isolated legalization framework we could use instead, but I'd like to not grow *two* legalization frameworks that the LLVM community (that is, not the SPIR-V maintainers) have to update when making general IR changes. I'm not sure what the best approach is here, but I think it's really critical to clearly and directly address this problem.

To give you an idea of what I'm worried about in #2, imagine that we both extend the IR to support some new construct, *and* we make that new construct *canonical*. This would cause the existing IR produced by frontends to optimize into something that the SPIR-V "target" wasn't prepared for and would have to be taught about to continue passing its basic tests. I would like for teaching the SPIR-V "target" to not be a completely separate overhead from teaching the actual machine targets about this, which we usually do today by providing an obvious legalization strategy for the new construct to the SelectionDAG and falling back to that on most targets.

I'm somewhat worried about this due to changes to the IR *operations*, but I'm actually more worried about changes to the IR *types* or even *type systems*. If the SPIR-V stuff doesn't do type legalization of some form, and we want to change the fundamental way LLVM deals with (for example) FCAs (whether to get rid of them, or handle them in a "better" way, or whatever), then I'm worried adding SPIR-V will add more road blocks to something that is already really hard. That doesn't seem like the right design to me.



All that said, I think it is totally fine to put the "frontend" which reads in SPIR-V and produces IR ... really wherever you want. It could live inside the "Target" as some have suggested or somewhere else. Having it live inside the "Target" would have some advantages of making it easy to exclude from a build if folks aren't using it (for whatever reason).

-Chandler

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
123