[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

Mehdi Amini-2

On May 20, 2015, at 7:13 AM, Neil Henning <[hidden email]> wrote:

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.

Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?
I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.

If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?
The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.

— 
Mehdi





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


_______________________________________________
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


On Thu, May 21, 2015 at 8:03 AM, Mehdi Amini <[hidden email]> wrote:

On May 20, 2015, at 7:13 AM, Neil Henning <[hidden email]> wrote:

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.

Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?

I would hope that we would run at least mem2reg/sroa, do those need data layout?

-- Sean Silva
 
I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.

If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?
The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.

— 
Mehdi





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



_______________________________________________
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 Majnemer


On Thu, May 21, 2015 at 1:50 PM, Sean Silva <[hidden email]> wrote:


On Thu, May 21, 2015 at 8:03 AM, Mehdi Amini <[hidden email]> wrote:

On May 20, 2015, at 7:13 AM, Neil Henning <[hidden email]> wrote:

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.

Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?

I would hope that we would run at least mem2reg/sroa, do those need data layout?

SROA assumes that it has DataLayout.
 

-- Sean Silva
 
I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.

If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?
The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.

— 
Mehdi





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



_______________________________________________
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

Yaxun Liu

The objective of SPIR-V is to provide a portable binary format for OpenCL kernels and GLSL shaders. For OpenCL 1.2 and 2.0 kernels, there is already spir-unknown-unknown and spir64-unknown-unknown target triple and corresponding data layout. Since many OpenCL vendors already support them, it is natural to extend them to support SPIR-V. Hopefully there will be a document about the restrictions, data types and metadata format of LLVM bitcode which can be translated to SPIR-V.

 

For optimizations, I think most of them should be allowed since they do not change the semantics. However, they should not change or delete the struct type names and metadata which carry information about OpenCL kernels.

 

Sam

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of David Majnemer
Sent: Thursday, May 21, 2015 5:59 PM
To: Sean Silva
Cc: [hidden email]
Subject: Re: [LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

 

 

 

On Thu, May 21, 2015 at 1:50 PM, Sean Silva <[hidden email]> wrote:

 

 

On Thu, May 21, 2015 at 8:03 AM, Mehdi Amini <[hidden email]> wrote:

 

On May 20, 2015, at 7:13 AM, Neil Henning <[hidden email]> wrote:

 

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.

 

Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?

 

I would hope that we would run at least mem2reg/sroa, do those need data layout?

 

SROA assumes that it has DataLayout.

 

 

-- Sean Silva

 

I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.

 

If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?

The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.

 

— 

Mehdi

 

 

 





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

 

 


_______________________________________________
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

Philip Reames-4
In reply to this post by Yaxun Liu
After following the thread through the rounds of discussion that have
happened, I have serious concern about this proposal and believe that it
should not land as proposed.  I am not opposed to the idea of SPIR, but
the current proposal is lacking key details and could be construed to
imply maintenance and support obligations on the community as a whole
which are not clearly defined, much less widely discussed and agreed to.

I would suggest that interested parties need to settle on a usage model,
what the model implies for the rest of LLVM, and come back with a more
detailed specific proposal.

 From what I've gathered so far, it really sounds like there are two
proposals within one here.

The first is a SPIR-frontend targeting arbitrary backends.  The usage
model sounds like an existing SPIR program being compiled to either x86
(say for testing purposes) or one of the existing GPU focused backends.  
To me, this sounds like the less invasive part since none of the
concerns about data layout (or lack there of) apply.  By the time we're
compiling a SPIR program to a particular target, we should be able to
optimize using target specific information.  My suggestion would be to
establish a new repository (hosted on llvm.org) which holds this
frontend.  I have seen no reason this should live in the main llvm or
clang repositories in the discussion to date.

The second sounds like it's a proposal to have Clang support an SPIR
backend.  Exactly what form this would take appears to be really unclear
and the implications for the project have not be spelled out.  In
particular, it's not clear to me that preserving all the invariants
needed to emit SPIR through the optimizer is even possible with our
current IR and type system.  I would be actively opposed to seeing
changes in this direction land without substaintial further discussion
and active contribution/ownership by an existing active member of the
LLVM community.

Philip

On 05/13/2015 05:56 AM, Liu, Yaxun (Sam) wrote:

> Khronos Group SPIR WG is working on a bi-way converter between LLVM bitcode and SPIR-V (https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary and is willing to upstream it to the LLVM project.
>
> The bi-way converter uses a common in-memory representation of SPIR-V. It works by breaking down a module to instructions and construct the translated module in memory then output it. Currently it supports SPIR-V common instructions and OpenCL specific instructions. Supporting of other languages is under consideration.
>
> We plan to refactor the LLVM to SPIR-V converter as a backend at llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this will result in an unconventional backend which does not use SelectionDAG/MC, we would like to know whether it is acceptable. We are open to the SelectionDAG/MC approach if the community recommends it.
>
> For the SPIR-V to LLVM converter, we are seeking suggestions on its proper location in the LLVM project.
>
> Any comments are welcome. Thanks.
>
> Yaxun Liu
> AMD
>
> _______________________________________________
> 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

Mehdi Amini-2
In reply to this post by Yaxun Liu

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

The objective of SPIR-V is to provide a portable binary format for OpenCL kernels and GLSL shaders. For OpenCL 1.2 and 2.0 kernels, there is already spir-unknown-unknown and spir64-unknown-unknown target triple and corresponding data layout. Since many OpenCL vendors already support them, it is natural to extend them to support SPIR-V. Hopefully there will be a document about the restrictions, data types and metadata format of LLVM bitcode which can be translated to SPIR-V.

 

For optimizations, I think most of them should be allowed since they do not change the semantics. However, they should not change or delete the struct type names and metadata which carry information about OpenCL kernels.


I’m not sure what you mean exactly by “they do not change the semantics”. Optimizations are data layout dependent and operate with some assumptions related to it, and having the IR optimized with one data layout and processed by a target with a different data layout is not supported. The IR after optimization should only be reused for targets that have a compatible data layout AFAIK. 

I’m not sure how this fit in SPIR-V? It seems that SPIR-V serialized from LLVM after optimization won't be target independent, and I’m not sure how is it handled/expressed in SPIR-V?

Thanks,

— 
Mehdi



 

Sam

 

From: [hidden email] [[hidden email]] On Behalf Of David Majnemer
Sent: Thursday, May 21, 2015 5:59 PM
To: Sean Silva
Cc: [hidden email]
Subject: Re: [LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

 

 

 

On Thu, May 21, 2015 at 1:50 PM, Sean Silva <[hidden email]> wrote:

 

 

On Thu, May 21, 2015 at 8:03 AM, Mehdi Amini <[hidden email]> wrote:

 

On May 20, 2015, at 7:13 AM, Neil Henning <[hidden email]> wrote:

 

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.

 

Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?

 

I would hope that we would run at least mem2reg/sroa, do those need data layout?

 

SROA assumes that it has DataLayout.

 

 

-- Sean Silva

 

I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.

 

If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?

The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.

 

— 

Mehdi

 

 

 





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

 

 


_______________________________________________
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

Neil Henning
In reply to this post by Philip Reames-4
'Maintenance and support obligations' - the only maintenance obligations
would be don't regress our tests when you change code, that is no
different from doing changes to any other target.

Chandler raised some pretty important points in his reply, and we will
need to address them. In Sam's original email he did say 'We are open to
the SelectionDAG/MC approach if the community recommends it.' <- I would
infer from Chandler's email that he is most definitely recommending
this, and if the community as a whole believes this is the direction we
should take then we are happy to proceed in that way.

Really though our 'proposal' is that we have code that does bi-way
conversion from LLVM IR <-> SPIR-V, we are asking the community where we
can place it in the tree that makes most sense. We believe that there
will be real benefit for people to write their own shader/kernel
languages using the awesome infrastructure that LLVM and Clang provides,
and I for one want to enable the community to do just that.

> I would be actively opposed to seeing changes in this direction land
> without substaintial further discussion and active
> contribution/ownership by an existing active member of the LLVM
> community.

We would be very happy for 'an existing active member of the LLVM
community' to help us in our endeavours, but to 'actively oppose' the
inclusion of our code based (aside from Chandler's concerns that I have
already addressed) on a minor niggle with the data layout (which as Sam
pointed out is as easy as using the data layout that exists at present
for the SPIR/SPIR64 targets) seems rather harsh.

The main issue of contention has been around 'is it a target'. I still
think the most unobtrusive way for us to proceed here is to add it as a
target that is only enabled via the experimental targets mechanism (like
many new targets have been before) and then we can evolve the code from
there.

-Neil.

On 22/05/15 06:34, Philip Reames wrote:

> After following the thread through the rounds of discussion that have
> happened, I have serious concern about this proposal and believe that
> it should not land as proposed.  I am not opposed to the idea of SPIR,
> but the current proposal is lacking key details and could be construed
> to imply maintenance and support obligations on the community as a
> whole which are not clearly defined, much less widely discussed and
> agreed to.
>
> I would suggest that interested parties need to settle on a usage
> model, what the model implies for the rest of LLVM, and come back with
> a more detailed specific proposal.
>
> From what I've gathered so far, it really sounds like there are two
> proposals within one here.
>
> The first is a SPIR-frontend targeting arbitrary backends.  The usage
> model sounds like an existing SPIR program being compiled to either
> x86 (say for testing purposes) or one of the existing GPU focused
> backends.  To me, this sounds like the less invasive part since none
> of the concerns about data layout (or lack there of) apply.  By the
> time we're compiling a SPIR program to a particular target, we should
> be able to optimize using target specific information.  My suggestion
> would be to establish a new repository (hosted on llvm.org) which
> holds this frontend.  I have seen no reason this should live in the
> main llvm or clang repositories in the discussion to date.
>
> The second sounds like it's a proposal to have Clang support an SPIR
> backend.  Exactly what form this would take appears to be really
> unclear and the implications for the project have not be spelled out.  
> In particular, it's not clear to me that preserving all the invariants
> needed to emit SPIR through the optimizer is even possible with our
> current IR and type system.  I would be actively opposed to seeing
> changes in this direction land without substaintial further discussion
> and active contribution/ownership by an existing active member of the
> LLVM community.
>
> Philip
>
> On 05/13/2015 05:56 AM, Liu, Yaxun (Sam) wrote:
>> Khronos Group SPIR WG is working on a bi-way converter between LLVM
>> bitcode and SPIR-V
>> (https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf ) binary
>> and is willing to upstream it to the LLVM project.
>>
>> The bi-way converter uses a common in-memory representation of
>> SPIR-V. It works by breaking down a module to instructions and
>> construct the translated module in memory then output it. Currently
>> it supports SPIR-V common instructions and OpenCL specific
>> instructions. Supporting of other languages is under consideration.
>>
>> We plan to refactor the LLVM to SPIR-V converter as a backend at
>> llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this
>> will result in an unconventional backend which does not use
>> SelectionDAG/MC, we would like to know whether it is acceptable. We
>> are open to the SelectionDAG/MC approach if the community recommends it.
>>
>> For the SPIR-V to LLVM converter, we are seeking suggestions on its
>> proper location in the LLVM project.
>>
>> Any comments are welcome. Thanks.
>>
>> Yaxun Liu
>> AMD
>>
>> _______________________________________________
>> 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

Philip Reames-4
Let me start by emphasizing that I only speak for myself.  This is my
opinion, and nothing more.

On 05/22/2015 03:55 AM, Neil Henning wrote:
> 'Maintenance and support obligations' - the only maintenance
> obligations would be don't regress our tests when you change code,
> that is no different from doing changes to any other target.
I think SPIR as discussed is different in two potentially important ways:
- The lack of target information.  Can we even run IR passes over SPIR
derived IR and get back valid SPIR?  This hasn't been resolved.
- SPIR has explicit compatibility provisions across versions. Adding a
bi-directional converter makes the community responsible for preserving
this compatibility, even in face of otherwise breaking IR changes.  I
haven't seen this clearly discussed yet.

>
> Chandler raised some pretty important points in his reply, and we will
> need to address them. In Sam's original email he did say 'We are open
> to the SelectionDAG/MC approach if the community recommends it.' <- I
> would infer from Chandler's email that he is most definitely
> recommending this, and if the community as a whole believes this is
> the direction we should take then we are happy to proceed in that way.
>
> Really though our 'proposal' is that we have code that does bi-way
> conversion from LLVM IR <-> SPIR-V, we are asking the community where
> we can place it in the tree that makes most sense. We believe that
> there will be real benefit for people to write their own shader/kernel
> languages using the awesome infrastructure that LLVM and Clang
> provides, and I for one want to enable the community to do just that.
Like I said, I'm not opposed to the idea of SPIR.  I'm not even opposed
to supporting SPIR w/in LLVM.  I am seriously concerned about the
*current proposal*.  I will also point out that I actively tried to
suggest a path forward with incremental progress being made.
>
>> I would be actively opposed to seeing changes in this direction land
>> without substaintial further discussion and active
>> contribution/ownership by an existing active member of the LLVM
>> community.
>
> We would be very happy for 'an existing active member of the LLVM
> community' to help us in our endeavours,
My reasoning here may not have been clear, and reading this out of
context it sounds more dismissive than I'd intended.  Sorry.

Most of my concerns about the proposal come down to issues of process,
community norms, and support.  By working with one or more folks who
have established histories in the community makes it easier to trust
that those issues will be resolved properly.  In particular, it makes it
far less likely that the contribution will end up being a "code drop"
w/o any ongoing active development.

> but to 'actively oppose' the inclusion of our code based (aside from
> Chandler's concerns that I have already addressed) on a minor niggle
> with the data layout (which as Sam pointed out is as easy as using the
> data layout that exists at present for the SPIR/SPIR64 targets) seems
> rather harsh.
I disagree.  By actively oppose, all I mean is that I will argue against
it in it's current form.  I am simply one contributor to LLVM.  If you
convince other folks that the current approach is sufficient, my
opposition doesn't matter to you in practice.

> The main issue of contention has been around 'is it a target'. I still
> think the most unobtrusive way for us to proceed here is to add it as
> a target that is only enabled via the experimental targets mechanism
> (like many new targets have been before) and then we can evolve the
> code from there.
At the moment, I don't see the "is it a target" as being the core
concerns.  The serialization, support, and data layout pieces are far
more concerning to me personally.

>
> -Neil.
>
> On 22/05/15 06:34, Philip Reames wrote:
>> After following the thread through the rounds of discussion that have
>> happened, I have serious concern about this proposal and believe that
>> it should not land as proposed.  I am not opposed to the idea of
>> SPIR, but the current proposal is lacking key details and could be
>> construed to imply maintenance and support obligations on the
>> community as a whole which are not clearly defined, much less widely
>> discussed and agreed to.
>>
>> I would suggest that interested parties need to settle on a usage
>> model, what the model implies for the rest of LLVM, and come back
>> with a more detailed specific proposal.
>>
>> From what I've gathered so far, it really sounds like there are two
>> proposals within one here.
>>
>> The first is a SPIR-frontend targeting arbitrary backends.  The usage
>> model sounds like an existing SPIR program being compiled to either
>> x86 (say for testing purposes) or one of the existing GPU focused
>> backends.  To me, this sounds like the less invasive part since none
>> of the concerns about data layout (or lack there of) apply.  By the
>> time we're compiling a SPIR program to a particular target, we should
>> be able to optimize using target specific information.  My suggestion
>> would be to establish a new repository (hosted on llvm.org) which
>> holds this frontend.  I have seen no reason this should live in the
>> main llvm or clang repositories in the discussion to date.
>>
>> The second sounds like it's a proposal to have Clang support an SPIR
>> backend.  Exactly what form this would take appears to be really
>> unclear and the implications for the project have not be spelled
>> out.  In particular, it's not clear to me that preserving all the
>> invariants needed to emit SPIR through the optimizer is even possible
>> with our current IR and type system. I would be actively opposed to
>> seeing changes in this direction land without substaintial further
>> discussion and active contribution/ownership by an existing active
>> member of the LLVM community.
>>
>> Philip
>>
>> On 05/13/2015 05:56 AM, Liu, Yaxun (Sam) wrote:
>>> Khronos Group SPIR WG is working on a bi-way converter between LLVM
>>> bitcode and SPIR-V
>>> (https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf )
>>> binary and is willing to upstream it to the LLVM project.
>>>
>>> The bi-way converter uses a common in-memory representation of
>>> SPIR-V. It works by breaking down a module to instructions and
>>> construct the translated module in memory then output it. Currently
>>> it supports SPIR-V common instructions and OpenCL specific
>>> instructions. Supporting of other languages is under consideration.
>>>
>>> We plan to refactor the LLVM to SPIR-V converter as a backend at
>>> llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this
>>> will result in an unconventional backend which does not use
>>> SelectionDAG/MC, we would like to know whether it is acceptable. We
>>> are open to the SelectionDAG/MC approach if the community recommends
>>> it.
>>>
>>> For the SPIR-V to LLVM converter, we are seeking suggestions on its
>>> proper location in the LLVM project.
>>>
>>> Any comments are welcome. Thanks.
>>>
>>> Yaxun Liu
>>> AMD
>>>
>>> _______________________________________________
>>> 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

_______________________________________________
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

Yaxun Liu
In reply to this post by Mehdi Amini-2

From: Mehdi Amini [[hidden email]]
Sent: Friday, May 22, 2015 1:54 AM

 

I’m not sure what you mean exactly by “they do not change the semantics”. Optimizations are data layout dependent and operate with some assumptions related to it, and having the IR optimized with one data layout and processed by a target with a different data layout is not supported. The IR after optimization should only be reused for targets that have a compatible data layout AFAIK. 

 

I’m not sure how this fit in SPIR-V? It seems that SPIR-V serialized from LLVM after optimization won't be target independent, and I’m not sure how is it handled/expressed in SPIR-V?

 

               Sorry for the late reply. I think your concern about data layout of SPIR-V is valid. My understanding is that in general SPIR-V needs to assume some data layout to express semantics of a program. Optimization should not use a data layout different than that of SPIR-V. We are working on this. Hopefully we will come back with an answer soon.

 

Thanks,

 

— 

Mehdi

 

 



 

Sam

 

From: [hidden email] [[hidden email]] On Behalf Of David Majnemer
Sent: Thursday, May 21, 2015 5:59 PM
To: Sean Silva
Cc:
[hidden email]
Subject: Re: [LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

 

 

 

On Thu, May 21, 2015 at 1:50 PM, Sean Silva <[hidden email]> wrote:

 

 

On Thu, May 21, 2015 at 8:03 AM, Mehdi Amini <[hidden email]> wrote:

 

On May 20, 2015, at 7:13 AM, Neil Henning <[hidden email]> wrote:

 

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.

 

Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?

 

I would hope that we would run at least mem2reg/sroa, do those need data layout?

 

SROA assumes that it has DataLayout.

 

 

-- Sean Silva

 

I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.

 

If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?

The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.

 

— 

Mehdi

 

 

 







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

 

 


_______________________________________________
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

Yaxun Liu
In reply to this post by Philip Reames-4
Sorry for my late reply.

Thanks for sharing your concerns. I commented about some technical concerns below. For the concerns about the ownership and long-term maintenance, I will bring them back to the SPIR WG. Hopefully we will come back with a satisfying solution.

Sam
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Philip Reames
Sent: Friday, May 22, 2015 12:29 PM
To: Neil Henning; [hidden email]
Subject: Re: [LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

On 05/22/2015 03:55 AM, Neil Henning wrote:
> 'Maintenance and support obligations' - the only maintenance
> obligations would be don't regress our tests when you change code,
> that is no different from doing changes to any other target.
I think SPIR as discussed is different in two potentially important ways:
- The lack of target information.  Can we even run IR passes over SPIR derived IR and get back valid SPIR?  This hasn't been resolved.
        + My understanding is that SPIR-V targets generic OpenCL/GL devices and assumes a common natural data layout. Optimizations allowed on SPIR-V should not introduce any target specific dependence. The common use case of SPIR-V is that a vendor generates SPIR-V with minor optimizations and sends it to a user. The user translates SPIR-V to LLVM and performs target-specific optimizations and codegen, and executes the ISA.
- SPIR has explicit compatibility provisions across versions. Adding a bi-directional converter makes the community responsible for preserving this compatibility, even in face of otherwise breaking IR changes.  I haven't seen this clearly discussed yet.
        + The current implementation of LLVM to SPIR-V converter works by breaking down the IR to instructions and constructing the corresponding entities in SPIR-V. The SPIR-V to LLVM converter works the other way around. Their dependence on the IR is mainly on the API for getting information about entities and creating entities in the IR. The dependence is not much different from other LLVM module passes. I have seen porting efforts of the converter among LLVM 3.2/3.4/3.6, which are no more difficult than typical LLVM module passes. For example, the main porting efforts from 3.4 to 3.6 is the change in API changes about metadata and user iterator, which are quite straightforward.

_______________________________________________
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 Bieneman
In reply to this post by Mehdi Amini-2

On May 21, 2015, at 8:03 AM, Mehdi Amini <[hidden email]> wrote:


On May 20, 2015, at 7:13 AM, Neil Henning <[hidden email]> wrote:

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.

Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?

Sorry, I’m just catching up on this thread, but I wanted to answer this question. I think it is reasonable that you could go frontend->IR->optimizer->IR->SPIR-V with one big caveat.

If I understand correctly from the SPIR-V spec, SPIR-V has some strict requirements. One of them is that control flow needs to be minimally structured. IR doesn’t have the same requirement, and some of our optimization passes may not preserve control flow structure (I’m looking at you jump threading). This means that prior to writing SPIR-V there will probably need to be either a verification step to ensure that the IR can be serialized to SPRI-V, or a fix-up step to make it serializable.

-Chris

I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.

If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?
The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.

— 
Mehdi





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

_______________________________________________
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

Daniel Berlin
In reply to this post by Philip Reames-4
On Fri, May 22, 2015 at 9:29 AM, Philip Reames
<[hidden email]> wrote:

> Let me start by emphasizing that I only speak for myself.  This is my
> opinion, and nothing more.
>
> On 05/22/2015 03:55 AM, Neil Henning wrote:
>>
>> 'Maintenance and support obligations' - the only maintenance obligations
>> would be don't regress our tests when you change code, that is no different
>> from doing changes to any other target.
>
> I think SPIR as discussed is different in two potentially important ways:
> - The lack of target information.  Can we even run IR passes over SPIR
> derived IR and get back valid SPIR?  This hasn't been resolved.
> - SPIR has explicit compatibility provisions across versions. Adding a
> bi-directional converter makes the community responsible for preserving this
> compatibility, even in face of otherwise breaking IR changes.  I haven't
> seen this clearly discussed yet.

Also, "don't regress tests" is a really strong obligation to impose if
"doing normal things to LLVM IR allowed by LLVM langref" may break
SPIR tests, because SPIR has stricter requirements and you test them
(and, if you don't test them, then the target is certain to break).
So as Philip says, this definitely sounds like something that needs
some real resolution.


>>
>>
>> Chandler raised some pretty important points in his reply, and we will
>> need to address them. In Sam's original email he did say 'We are open to the
>> SelectionDAG/MC approach if the community recommends it.' <- I would infer
>> from Chandler's email that he is most definitely recommending this, and if
>> the community as a whole believes this is the direction we should take then
>> we are happy to proceed in that way.
>>
>> Really though our 'proposal' is that we have code that does bi-way
>> conversion from LLVM IR <-> SPIR-V,


And if you test this, as Philip says,  the llvm community becomes
responsible for ensuring compatibility/figuring out ways to make this
translation into SPIR (which uh, AFAICT, was developed in part because
the llvm community didn't want to guarantee this :P).

How do you propose that work, exactly (literally, i'm not suggesting
it doesn't, i'm trying to understand the proposed moel)?

Let me give a practical example:

David Blaikie has been working on removing pointer types from some
places and adding them in others, to remove requirements to bitcast
pointers.

This requires bitcode changes, and IR/langref changes.

SPIR, even if it were to follow in the same path, does not in fact do
this right now.

In the LLVM bitcode/IR, one-way translation (from old bitcode to new)
from old to new is easy.
Two way translation from old to new is much harder (now he really has
to have a pass to output bitcasts where they don't exist now to match
the semantics of the old IR).  But that is what is essentially going
to need to be done.

Thus, if you test the SPIR translation of LLVM load/stores/geps, you
would be affected by these changes.
Do you expect David to write that part of a conversion pass/or update
any existing conversion pass to make these changes to not break your
tests?

If so, you are asking the LLVM community to take on the burden of
supporting the SPIR serialization, essentially, and that will
significantly change the ability of the llvm community to innovate
LLVM's IR.
If not, what is the process you expect to be followed here?

IE do you expect him to break you, wait for SPIR to decide whether
they want to do the same thing, etc?
_______________________________________________
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
Hey Daniel!

So based on Philip and Chandler's points I really think the easiest way
to integrate SPIR-V with LLVM is how I originally envisaged it - EG. we
only put the production of SPIR-V within LLVM, and we integrate it fully
as a backend.

It was under this assumption that my comment of "don't regress tests" is
valid - EG. we would be a normal backend like the other backends and
would have a similar testing approach to the other backends. In this
regard the changes you mentioned that David Blaikie is doing wouldn't in
theory require any extra work on his or anyone else's part.

I think if we follow this approach we provide the easiest method to
integrate with LLVM, while putting no additional burden on the common
infrastructure that is worrying the community so much :)

Cheers,
-Neil.

On 26/05/15 22:22, Daniel Berlin wrote:

> On Fri, May 22, 2015 at 9:29 AM, Philip Reames
> <[hidden email]> wrote:
>> Let me start by emphasizing that I only speak for myself.  This is my
>> opinion, and nothing more.
>>
>> On 05/22/2015 03:55 AM, Neil Henning wrote:
>>> 'Maintenance and support obligations' - the only maintenance obligations
>>> would be don't regress our tests when you change code, that is no different
>>> from doing changes to any other target.
>> I think SPIR as discussed is different in two potentially important ways:
>> - The lack of target information.  Can we even run IR passes over SPIR
>> derived IR and get back valid SPIR?  This hasn't been resolved.
>> - SPIR has explicit compatibility provisions across versions. Adding a
>> bi-directional converter makes the community responsible for preserving this
>> compatibility, even in face of otherwise breaking IR changes.  I haven't
>> seen this clearly discussed yet.
> Also, "don't regress tests" is a really strong obligation to impose if
> "doing normal things to LLVM IR allowed by LLVM langref" may break
> SPIR tests, because SPIR has stricter requirements and you test them
> (and, if you don't test them, then the target is certain to break).
> So as Philip says, this definitely sounds like something that needs
> some real resolution.
>
>
>>>
>>> Chandler raised some pretty important points in his reply, and we will
>>> need to address them. In Sam's original email he did say 'We are open to the
>>> SelectionDAG/MC approach if the community recommends it.' <- I would infer
>>> from Chandler's email that he is most definitely recommending this, and if
>>> the community as a whole believes this is the direction we should take then
>>> we are happy to proceed in that way.
>>>
>>> Really though our 'proposal' is that we have code that does bi-way
>>> conversion from LLVM IR <-> SPIR-V,
>
> And if you test this, as Philip says,  the llvm community becomes
> responsible for ensuring compatibility/figuring out ways to make this
> translation into SPIR (which uh, AFAICT, was developed in part because
> the llvm community didn't want to guarantee this :P).
>
> How do you propose that work, exactly (literally, i'm not suggesting
> it doesn't, i'm trying to understand the proposed moel)?
>
> Let me give a practical example:
>
> David Blaikie has been working on removing pointer types from some
> places and adding them in others, to remove requirements to bitcast
> pointers.
>
> This requires bitcode changes, and IR/langref changes.
>
> SPIR, even if it were to follow in the same path, does not in fact do
> this right now.
>
> In the LLVM bitcode/IR, one-way translation (from old bitcode to new)
> from old to new is easy.
> Two way translation from old to new is much harder (now he really has
> to have a pass to output bitcasts where they don't exist now to match
> the semantics of the old IR).  But that is what is essentially going
> to need to be done.
>
> Thus, if you test the SPIR translation of LLVM load/stores/geps, you
> would be affected by these changes.
> Do you expect David to write that part of a conversion pass/or update
> any existing conversion pass to make these changes to not break your
> tests?
>
> If so, you are asking the LLVM community to take on the burden of
> supporting the SPIR serialization, essentially, and that will
> significantly change the ability of the llvm community to innovate
> LLVM's IR.
> If not, what is the process you expect to be followed here?
>
> IE do you expect him to break you, wait for SPIR to decide whether
> they want to do the same thing, etc?

_______________________________________________
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

Petr Hosek
To chime in, I have been dealing with similar issue recently in the case of PNaCl which also uses a custom bitcode reader/writer. I was originally thinking about creating a custom backend for Le32 virtual architecture, but in the end I settled on the solution implemented entirely in Clang.

I extended the ToolChain class by adding a `isVirtualTarget` method a created new Generic_BC (similar to the existing Generic_ELF) subclass which can be used by any target operating on bitcode. Any toolchain which inherits from Generic_BC behaves as if the -emit-llvm flag was on the command line (without actually having to pass this flag) and skips the Assembly phase, but still going through the Linking phase. To emit the PNaCl bitcode, we use a modified version of gold plugin to link all the bitcode files together and then run the PNaCl bitcode writer.

I'm happy to submit this patch if you believe it would be useful to SPIR-V (or other targets with similar requirements).

On Tue, May 26, 2015 at 2:39 PM Neil Henning <[hidden email]> wrote:
Hey Daniel!

So based on Philip and Chandler's points I really think the easiest way
to integrate SPIR-V with LLVM is how I originally envisaged it - EG. we
only put the production of SPIR-V within LLVM, and we integrate it fully
as a backend.

It was under this assumption that my comment of "don't regress tests" is
valid - EG. we would be a normal backend like the other backends and
would have a similar testing approach to the other backends. In this
regard the changes you mentioned that David Blaikie is doing wouldn't in
theory require any extra work on his or anyone else's part.

I think if we follow this approach we provide the easiest method to
integrate with LLVM, while putting no additional burden on the common
infrastructure that is worrying the community so much :)

Cheers,
-Neil.

On 26/05/15 22:22, Daniel Berlin wrote:
> On Fri, May 22, 2015 at 9:29 AM, Philip Reames
> <[hidden email]> wrote:
>> Let me start by emphasizing that I only speak for myself.  This is my
>> opinion, and nothing more.
>>
>> On 05/22/2015 03:55 AM, Neil Henning wrote:
>>> 'Maintenance and support obligations' - the only maintenance obligations
>>> would be don't regress our tests when you change code, that is no different
>>> from doing changes to any other target.
>> I think SPIR as discussed is different in two potentially important ways:
>> - The lack of target information.  Can we even run IR passes over SPIR
>> derived IR and get back valid SPIR?  This hasn't been resolved.
>> - SPIR has explicit compatibility provisions across versions. Adding a
>> bi-directional converter makes the community responsible for preserving this
>> compatibility, even in face of otherwise breaking IR changes.  I haven't
>> seen this clearly discussed yet.
> Also, "don't regress tests" is a really strong obligation to impose if
> "doing normal things to LLVM IR allowed by LLVM langref" may break
> SPIR tests, because SPIR has stricter requirements and you test them
> (and, if you don't test them, then the target is certain to break).
> So as Philip says, this definitely sounds like something that needs
> some real resolution.
>
>
>>>
>>> Chandler raised some pretty important points in his reply, and we will
>>> need to address them. In Sam's original email he did say 'We are open to the
>>> SelectionDAG/MC approach if the community recommends it.' <- I would infer
>>> from Chandler's email that he is most definitely recommending this, and if
>>> the community as a whole believes this is the direction we should take then
>>> we are happy to proceed in that way.
>>>
>>> Really though our 'proposal' is that we have code that does bi-way
>>> conversion from LLVM IR <-> SPIR-V,
>
> And if you test this, as Philip says,  the llvm community becomes
> responsible for ensuring compatibility/figuring out ways to make this
> translation into SPIR (which uh, AFAICT, was developed in part because
> the llvm community didn't want to guarantee this :P).
>
> How do you propose that work, exactly (literally, i'm not suggesting
> it doesn't, i'm trying to understand the proposed moel)?
>
> Let me give a practical example:
>
> David Blaikie has been working on removing pointer types from some
> places and adding them in others, to remove requirements to bitcast
> pointers.
>
> This requires bitcode changes, and IR/langref changes.
>
> SPIR, even if it were to follow in the same path, does not in fact do
> this right now.
>
> In the LLVM bitcode/IR, one-way translation (from old bitcode to new)
> from old to new is easy.
> Two way translation from old to new is much harder (now he really has
> to have a pass to output bitcasts where they don't exist now to match
> the semantics of the old IR).  But that is what is essentially going
> to need to be done.
>
> Thus, if you test the SPIR translation of LLVM load/stores/geps, you
> would be affected by these changes.
> Do you expect David to write that part of a conversion pass/or update
> any existing conversion pass to make these changes to not break your
> tests?
>
> If so, you are asking the LLVM community to take on the burden of
> supporting the SPIR serialization, essentially, and that will
> significantly change the ability of the llvm community to innovate
> LLVM's IR.
> If not, what is the process you expect to be followed here?
>
> IE do you expect him to break you, wait for SPIR to decide whether
> they want to do the same thing, etc?

_______________________________________________
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
123