[llvm-dev] [SPIR-V] SPIR-V in LLVM

Tue May 9 03:13:40 PDT 2017

(Given there are two Neil's on this thread, I'll use Codeplay Neil as an 
alias to differentiate!)

SPIR-V is constrained in the environment specs that consume it - 
https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/doc/specs/vulkan/appendices/spirvenv.txt 
for Vulkan 1.0.

Vulkan does not support i8 types (currently), and has optional i16, i64, 
f64 types.

SPIR-V as a thing does not have these constraints though, so outwith an 
environment (we're losing the usefulness of SPIR-V without being able to 
feed it to a Vulkan/OpenCL driver) it can support arbitrary type widths.

Cheers,
- Codeplay Neil.

On 2017-05-09 08:53, Nicholas Wilson via llvm-dev wrote:
> While in practice most SPIR-V consumers are going to only accept
> i16/32/64, f/16/32/64 and pointers as the base types, I couldn't
> actually find anything in the spec that says otherwise. This is
> particularly relevant for FPGAs that can support arbitrary integers
> (not sure about their consumers / synthesis tools though). Perhaps I
> should seek clarification from Khronos and maybe add that as a new
> capability.
> 
> -------------------------
> 
> FROM: Friedman, Eli <efriedma at codeaurora.org>
> SENT: Tuesday, 9 May 2017 1:31:58 AM
> TO: tstellar at redhat.com; Nicholas Wilson
> CC: llvm-dev at lists.llvm.org
> SUBJECT: Re: [llvm-dev] [SPIR-V] SPIR-V in LLVM
> 
> On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote:
>> On 05/03/2017 11:19 AM, Nicholas Wilson wrote:
>>>> Right, what I was trying to say is that there are more benefits
> from
>>>> having this not be a target than there is from having it be a
> target.
>>> Please enumerate them, I have seen none posted so far . The implied
> “it is what all the the other backends do” w.r.t ISel/MC is at
> best(worst?) an implementation detail, and I’m still not quite sure
> why Chandler was so adamant about that. He seemed to imply that
> generating straight from the IR (as opposed to post legalisation?)
> introduces a direct dependance in the IR that the rest of LLVM would
> then be required to not break? I agree that the SPIRV backend should
> be insulated from changes the IR, although I’m not sure how to
> achieve that property. I’m also not sure how much, if at all, it
> would be susceptible to that to begin with. Deletions of
> instructions/attributes would obviously cause breakage and additions
> may cause unhandled and/or invalid combinations. I still don’t get
> the severity if this though, insight appreciated.
>>> 
>> So there are really two questions here:
>> 1. Should targets be required to use SelectionDAG/GlobalISEL ?
>> 2. Should SPIR-V use SelectionDAG/GlobalISel?
>> 
>> In my opinion, regardless of the answer to question #1, the answer
>> to question #2 is no, SPIR-V should not use SelectionDAG/GlobalISel.
>> 
>> I touched on this before in previous emails, but the main problem is
> that
>> SelectionDAG (and GlobalISel to a lesser extent) plus the whole
> MachineInstr
>> layer is a much lower-level representation than SPIR-V, so you will
>> need to do a lot of extra work and/or modifications to existing
>> infrastructure in order to get a working target, and even then
>> you may be limited to emitting poor quality SPIR-V that other
>> backends will have a hard time optimizing.
>> 
>> With all this work, what advantages are you getting? If the
>> only reason to do it this way is so you can use intrinsics,
>> or TargetLibraryInfo, or easier integration with other tools,
>> I think it would be better to try to save the effort and try
>> to solve those problems in some other way.
>> 
>> LLVM IR -> SPIR-V directly will give you better code, lower compile
>> times. It will be more simple and easier to maintain, and you will
>> be able to re-use existing SPIR-V parsers/writers that exist
>> in SPIRV-Tools.
>> 
>> This goes back to something I mentioned in my original email, but
>> I really think the best thing to do for this project right now is to
>> keep it separate from LLVM, clean up the code, and try to get people
>> using it. It's going to be much easier to get this upstream in LLVM
> or
>> even convince people that the answer to question #1 should be 'no'
> if we
>> have a code base that is mature, well supported, and has a healthy
>> userbase.
>> 
> This is completely skipping over one very important step which is
> currently part of ISel: legalization. The LLVM optimizers expect
> backends to support arbitrary-width integers, arbitrary-width vectors,
> 
> and target-independent intrinsics which are lowered by legalization.
> SPIR-V does not have native support for these, therefore you need the
> legalization framework. And the legalization framework in LLVM is
> fundamentally tied to ISel.
> 
> -Eli
> 
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev