[LLVMdev] [RFC] Proposal for Adding SPIRV Target
Neil Henning
llvm at duskborn.com
Tue Jul 7 07:54:02 PDT 2015
Hey Tom,
Really it was at the behest of the replies - we got a lot of feedback
from the mailing list that indicated we'd be putting extra workload of
people changing features of the IR if we didn't follow the same
mechanisms of the other backends (mostly led by Chandler's very astute
comments on the subject).
Cheers,
-Neil.
On 07/07/15 14:43, Tom Stellard wrote:
> On Tue, Jul 07, 2015 at 10:17:20AM +0100, Neil Henning wrote:
>> 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.
> Can you give details on how you reached this conclusion? Why was this
> determined to be better than the alternatives?
>
> Thanks,
> Tom
>
>> * 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
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
More information about the llvm-dev
mailing list