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

Wed May 10 05:26:16 PDT 2017

Totally agree Philip! I think the main pending issue is are we allowed 
to have a target that doesn't go through the normal mechanisms that 
targets adhere to - and is basically just a ModulePass underneath.

In light of how thorny this request has been perceived in the past, I'd 
honestly rather just make external targets work _without_ patching LLVM 
being a requirement, and then any SPIR-V target (or any other external 
LLVM targets too!) can live, mature, and prove its usefulness while 
there is an avenue to use vanilla tip LLVM with the SPIR-V target and go 
through the normal mechanisms.

Cheers,
-Codeplay Neil.

On 2017-05-10 03:52, Philip Reames via llvm-dev wrote:
> 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
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev