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

Thu Jun 22 02:27:50 PDT 2017

Yup - entirely possible to have targets that are basically just one or 
more ModulePass's.

I also agree that lib/CodeGen would hinder rather than help us (which is 
why I stuck with using a few ModulePass's instead!)

- Codeplay Neil.

On 2017-06-21 19:06, Matthias Braun wrote:
> At least in principle LLVM is designed to have Targets that are not
> based on lib/CodeGen.
> 
> Looking at the APIs it should be possible to just implement
> TargetMachine (but not LLVMTargetMachine which is only meant for
> lib/CodeGen targets) and register that with the target registry.
> 
> Note that I have never actually done so, so I may be missing some
> things. It also seems the last non-CodeGen target in public tree was
> the cpp target which was removed a few years ago so hopefully the API
> has not regressed without testing.
> 
> Still I think it would be a good idea to at least evaluate/try this as
> I've got the feeling lib/CodeGen may get more in the way than being
> helpful in this case...
> 
> - Matthias
> 
>> On May 10, 2017, at 5:26 AM, Neil Henning via llvm-dev 
>> <llvm-dev at lists.llvm.org> wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev