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

[Nicholas Wilson via llvm-dev]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170509/399752e3/attachment.html>