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

[Philip Reames via llvm-dev]

On 05/08/2017 10:31 AM, Friedman, Eli via llvm-dev wrote:
> 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.
I'll just add a non-technical point here.  Beyond the technical merits 
of "being a target" vs "not being a target" (which I will admit I've 
mostly skipped in this thread because it appears to be repeating 
previously discussed material), there is a *much* lower barrier to entry 
for "being a target".  We have standards in place for new targets; we're 
use to thinking about new targets.  If you want to add something 
fundamentally new, that will require a lot more design buy in and will 
have to clear a higher bar (in practice.)  Given I see little evidence 
of such buy-in to date, pursuing a "not a target strategy" will be 
substantially more risky.

Philip