On Thu, Jun 18, 2015 at 10:26 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:> > On Jun 18, 2015, at 9:31 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > > > *From:* Mehdi Amini [mailto:mehdi.amini at apple.com <mehdi.amini at apple.com>] > > *Sent:* Thursday, June 18, 2015 11:24 AM > *To:* Liu, Yaxun (Sam) > *Cc:* llvmdev at cs.uiuc.edu > *Subject:* Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target > > > > On Jun 18, 2015, at 6:23 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > Hi Mehdi, > > Thank you for your comments. My comments are below. > > Sam > > *From:* Mehdi Amini [mailto:mehdi.amini at apple.com <mehdi.amini at apple.com>] > > *Sent:* Wednesday, June 17, 2015 12:43 PM > *To:* Liu, Yaxun (Sam) > *Cc:* llvmdev at cs.uiuc.edu > *Subject:* Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target > > Hi Liu, > > Thanks for the detailed proposal. > > > > On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > Here is the revised proposal for the LLVM/SPIR-V converter. Please > comment. Thanks. > > Proposal of Adding SPIRV Target > > Background > > SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A > typical use case of SPIR-V is as follows: > > 1. An application developer uses Clang to compile an OpenCL kernel > source code to a SPIR-V binary which is common for all OpenCL platforms. > 2. The application developer ships the application containing the > SPIR-V binary to customers. > 3. A customer runs the application on an OpenCL platform, which > loads the SPIR-V binary through an OpenCL API function. > 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, > changes the target triple and data layout to suit the device which will > execute the kernel, performs target specific optimizations, generates the > ISA and executes the ISA on the device. > > > > Step 4 of your “typical use case” includes "changes the target triple and > data layout to suit the device which will execute the kernel”. It implies > that SPIR-V is data layout agnostic since you can load it with any data > layout, or there are (to be specified) constraint on what a “compatible” > data layout is, or you considered that it is up to the OpenCL vendor to > figure out what will work or not, with the drawback that any LLVM update > can break its use case. > > + For OpenCL, LLVM IR translated from SPIR-V has specific data layouts, > which are the data layouts for target spir/spir64. OpenCL vendor’s target > data layout are assumed to be consistent with them. > > > > For OpenCL kernels, there is implicit data layout dependence when > compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, > a common data layout accepted by different OpenCL vendors is required. We > choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, > since it has been successfully used for supporting consumption of SPIR > 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under > discussion whether to choose the same data layout as OpenCL, or a different > data layout, or no data layout at all. > > Location > > From feedback of the previous version of the proposal, there are several > suggestions about the location for the LLVM/SPIR-V converter: > > 1. llvm/lib/SPIRV only, adding an option to Clang for outputting > SPIR-V. The advantage is ease of use for bi-way translation. However it > does not reflect the fact that only LLVM IR with specific target triple and > data layout can be translated to SPIR-V. > > How important is it to “reflect it”? > The SPIR-V emitter could just assert on the data layout matching what is > expected. > + Putting the converter at llvm/lib/SPIRV may encourage misuse of the > converter, i.e., using the converter to convert LLVM IR of arbitrary > target, whereas the converter can only convert LLVM IR with spir/spir64 > target. > > > > I don’t know how the discussion about SelectionDAG impact your plan. > If the IR -> SPIR-V path is implemented as a “regular” target using the > legalization framework and so on, almost all the code will be in > lib/Target/SPIRV. > However it is not clear to me why the SPIR-V -> IR path would benefit in > any way to be there as well? > > Conceptually I should be able to compile LLVM and disable the SPIR-V > backend but still be able to read-in SPIR-V and target my fancy OpenCL > compliant device with my backend. > + The rationale is that SPIR-V is an alternative representation of LLVM IR > for spir/spir64 target. Therefore bi-way translation between LLVM and > SPIR-V is possible. Such functionality naturally belongs to the target. The > user who needs the translation functionality needs to link to the SPIRV > target library. > > > > It doesn’t not seem “natural” to me that a “target” backend would operate > as a “source”. > It is not clear also what piece of the target infrastructure would be > helpful to convert from SPIR-V to IR. > At some point there was a C target backend, it still would seem silly to > implement clang as a target. > >+1 It's highly unusual for lib/Target to implement X-to-LLVM-IR conversions. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/79549e87/attachment.html>
From: Eli Bendersky [mailto:eliben at google.com] Sent: Thursday, June 18, 2015 1:43 PM To: Mehdi Amini Cc: Liu, Yaxun (Sam); llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target On Thu, Jun 18, 2015 at 10:26 AM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: On Jun 18, 2015, at 9:31 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: From: Mehdi Amini [mailto:mehdi.amini at apple.com] Sent: Thursday, June 18, 2015 11:24 AM To: Liu, Yaxun (Sam) Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target On Jun 18, 2015, at 6:23 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Hi Mehdi, Thank you for your comments. My comments are below. Sam From: Mehdi Amini [mailto:mehdi.amini at apple.com] Sent: Wednesday, June 17, 2015 12:43 PM To: Liu, Yaxun (Sam) Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target Hi Liu, Thanks for the detailed proposal. On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Here is the revised proposal for the LLVM/SPIR-V converter. Please comment. Thanks. Proposal of Adding SPIRV Target Background SPIR-V is a portable binary format for OpenCL kernels and GLSL shaders. A typical use case of SPIR-V is as follows: 1. An application developer uses Clang to compile an OpenCL kernel source code to a SPIR-V binary which is common for all OpenCL platforms. 2. The application developer ships the application containing the SPIR-V binary to customers. 3. A customer runs the application on an OpenCL platform, which loads the SPIR-V binary through an OpenCL API function. 4. The vendor-specific OpenCL runtime translates SPIR-V to LLVM IR, changes the target triple and data layout to suit the device which will execute the kernel, performs target specific optimizations, generates the ISA and executes the ISA on the device. Step 4 of your “typical use case” includes "changes the target triple and data layout to suit the device which will execute the kernel”. It implies that SPIR-V is data layout agnostic since you can load it with any data layout, or there are (to be specified) constraint on what a “compatible” data layout is, or you considered that it is up to the OpenCL vendor to figure out what will work or not, with the drawback that any LLVM update can break its use case. + For OpenCL, LLVM IR translated from SPIR-V has specific data layouts, which are the data layouts for target spir/spir64. OpenCL vendor’s target data layout are assumed to be consistent with them. For OpenCL kernels, there is implicit data layout dependence when compiling the source to LLVM. Since SPIR-V is for common OpenCL platforms, a common data layout accepted by different OpenCL vendors is required. We choose the data layout which has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been successfully used for supporting consumption of SPIR 1.2/2.0 on various OpenCL platforms. For GLSL shaders, it is still under discussion whether to choose the same data layout as OpenCL, or a different data layout, or no data layout at all. Location From feedback of the previous version of the proposal, there are several suggestions about the location for the LLVM/SPIR-V converter: 1. llvm/lib/SPIRV only, adding an option to Clang for outputting SPIR-V. The advantage is ease of use for bi-way translation. However it does not reflect the fact that only LLVM IR with specific target triple and data layout can be translated to SPIR-V. How important is it to “reflect it”? The SPIR-V emitter could just assert on the data layout matching what is expected. + Putting the converter at llvm/lib/SPIRV may encourage misuse of the converter, i.e., using the converter to convert LLVM IR of arbitrary target, whereas the converter can only convert LLVM IR with spir/spir64 target. I don’t know how the discussion about SelectionDAG impact your plan. If the IR -> SPIR-V path is implemented as a “regular” target using the legalization framework and so on, almost all the code will be in lib/Target/SPIRV. However it is not clear to me why the SPIR-V -> IR path would benefit in any way to be there as well? Conceptually I should be able to compile LLVM and disable the SPIR-V backend but still be able to read-in SPIR-V and target my fancy OpenCL compliant device with my backend. + The rationale is that SPIR-V is an alternative representation of LLVM IR for spir/spir64 target. Therefore bi-way translation between LLVM and SPIR-V is possible. Such functionality naturally belongs to the target. The user who needs the translation functionality needs to link to the SPIRV target library. It doesn’t not seem “natural” to me that a “target” backend would operate as a “source”. It is not clear also what piece of the target infrastructure would be helpful to convert from SPIR-V to IR. At some point there was a C target backend, it still would seem silly to implement clang as a target. +1 It's highly unusual for lib/Target to implement X-to-LLVM-IR conversions. Eli OK how about let’s keep the original location. Keep the converter in lib/SPIRV and add a thin wrapper in lib/Target/SPIRV for now. As refactoring work goes on and lib/Target/SPIRV becomes full-fledged, phase out the SPIRV writer in lib/SPIRV. This also helps keep the SelectionDAG/MC implementation cleaner. Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150618/eba71c13/attachment.html>
So we have been in discussions within the Khronos SPIR-V work group on
our push to get our SPIR-V code into tip LLVM and have drawn the
following conclusions;
* We absolutely must create a fully fledged backend that uses all the
machinery that target backends are expected to use.
* We probably have to split out the SPIR-V -> LLVM IR into a separate
project from LLVM ala Clang et al.
As we want to allow developers to use the SPIR-V production/consumption
code now, and the time sink doing the above approach would incur, we are
going to open source the current work on the Khronos GitHub page as a
first step.
We intend to revisit introducing a SPIR-V backend to LLVM in the future.
Cheers,
-Neil.
On 18/06/15 20:25, Liu, Yaxun (Sam) wrote:>
> *From:*Eli Bendersky [mailto:eliben at google.com]
> *Sent:* Thursday, June 18, 2015 1:43 PM
> *To:* Mehdi Amini
> *Cc:* Liu, Yaxun (Sam); llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target
>
> On Thu, Jun 18, 2015 at 10:26 AM, Mehdi Amini <mehdi.amini at apple.com
> <mailto:mehdi.amini at apple.com>> wrote:
>
> On Jun 18, 2015, at 9:31 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com
> <mailto:Yaxun.Liu at amd.com>> wrote:
>
> *From:* Mehdi Amini [mailto:mehdi.amini at apple.com]
> *Sent:* Thursday, June 18, 2015 11:24 AM
> *To:* Liu, Yaxun (Sam)
> *Cc:* llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>
> *Subject:* Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target
>
> On Jun 18, 2015, at 6:23 AM, Liu, Yaxun (Sam)
> <Yaxun.Liu at amd.com <mailto:Yaxun.Liu at amd.com>>
wrote:
>
> Hi Mehdi,
>
> Thank you for your comments. My comments are below.
>
> Sam
>
> *From:* Mehdi Amini [mailto:mehdi.amini at apple.com]
> *Sent:* Wednesday, June 17, 2015 12:43 PM
> *To:* Liu, Yaxun (Sam)
> *Cc:* llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>
> *Subject:* Re: [LLVMdev] [RFC] Proposal for Adding SPIRV Target
>
> Hi Liu,
>
> Thanks for the detailed proposal.
>
> On Jun 17, 2015, at 5:44 AM, Liu, Yaxun (Sam)
> <Yaxun.Liu at amd.com <mailto:Yaxun.Liu at
amd.com>> wrote:
>
> Here is the revised proposal for the LLVM/SPIR-V
> converter. Please comment. Thanks.
>
> Proposal of Adding SPIRV Target
>
> Background
>
> SPIR-V is a portable binary format for OpenCL kernels and
> GLSL shaders. A typical use case of SPIR-V is as follows:
>
> 1.An application developer uses Clang to compile an OpenCL
> kernel source code to a SPIR-V binary which is common for
> all OpenCL platforms.
>
> 2.The application developer ships the application
> containing the SPIR-V binary to customers.
>
> 3.A customer runs the application on an OpenCL platform,
> which loads the SPIR-V binary through an OpenCL API function.
>
> 4.The vendor-specific OpenCL runtime translates SPIR-V to
> LLVM IR, changes the target triple and data layout to suit
> the device which will execute the kernel, performs target
> specific optimizations, generates the ISA and executes the
> ISA on the device.
>
> Step 4 of your “typical use case” includes "changes the target
> triple and data layout to suit the device which will execute
> the kernel”. It implies that SPIR-V is data layout agnostic
> since you can load it with any data layout, or there are (to
> be specified) constraint on what a “compatible” data layout
> is, or you considered that it is up to the OpenCL vendor to
> figure out what will work or not, with the drawback that any
> LLVM update can break its use case.
>
> + For OpenCL, LLVM IR translated from SPIR-V has specific data
> layouts, which are the data layouts for target spir/spir64.
> OpenCL vendor’s target data layout are assumed to be
> consistent with them.
>
> For OpenCL kernels, there is implicit data layout dependence
> when compiling the source to LLVM. Since SPIR-V is for common
> OpenCL platforms, a common data layout accepted by different
> OpenCL vendors is required. We choose the data layout which
> has been adopted by SPIR 1.2/2.0 for SPIR-V, since it has been
> successfully used for supporting consumption of SPIR 1.2/2.0
> on various OpenCL platforms. For GLSL shaders, it is still
> under discussion whether to choose the same data layout as
> OpenCL, or a different data layout, or no data layout at all.
>
> Location
>
> From feedback of the previous version of the proposal, there
> are several suggestions about the location for the LLVM/SPIR-V
> converter:
>
> 1.llvm/lib/SPIRV only, adding an option to Clang for
> outputting SPIR-V. The advantage is ease of use for bi-way
> translation. However it does not reflect the fact that only
> LLVM IR with specific target triple and data layout can be
> translated to SPIR-V.
>
> How important is it to “reflect it”?
>
> The SPIR-V emitter could just assert on the data layout
> matching what is expected.
>
> + Putting the converter at llvm/lib/SPIRV may encourage misuse
> of the converter, i.e., using the converter to convert LLVM IR
> of arbitrary target, whereas the converter can only convert
> LLVM IR with spir/spir64 target.
>
> I don’t know how the discussion about SelectionDAG impact your plan.
>
> If the IR -> SPIR-V path is implemented as a “regular” target
> using the legalization framework and so on, almost all the code
> will be in lib/Target/SPIRV.
>
> However it is not clear to me why the SPIR-V -> IR path would
> benefit in any way to be there as well?
>
> Conceptually I should be able to compile LLVM and disable the
> SPIR-V backend but still be able to read-in SPIR-V and target my
> fancy OpenCL compliant device with my backend.
>
> + The rationale is that SPIR-V is an alternative representation of
> LLVM IR for spir/spir64 target. Therefore bi-way translation
> between LLVM and SPIR-V is possible. Such functionality naturally
> belongs to the target. The user who needs the translation
> functionality needs to link to the SPIRV target library.
>
> It doesn’t not seem “natural” to me that a “target” backend would
> operate as a “source”.
>
> It is not clear also what piece of the target infrastructure would be
> helpful to convert from SPIR-V to IR.
>
> At some point there was a C target backend, it still would seem silly
> to implement clang as a target.
>
> +1
>
> It's highly unusual for lib/Target to implement X-to-LLVM-IR
conversions.
>
> Eli
>
> OK how about let’s keep the original location. Keep the converter in
> lib/SPIRV and add a thin wrapper in lib/Target/SPIRV for now. As
> refactoring work goes on and lib/Target/SPIRV becomes full-fledged,
> phase out the SPIRV writer in lib/SPIRV. This also helps keep the
> SelectionDAG/MC implementation cleaner.
>
> Sam
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150707/85da5167/attachment.html>