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

[Tom Stellard via llvm-dev]

On 05/01/2017 09:44 PM, Nicholas Wilson wrote:
> 
>> On 2 May 2017, at 8:48 am, Tom Stellard <tstellar at redhat.com> wrote:
>> You would probably need to write a new tablegen backend to generate
>> instruction tables that would be used outside of LLVM.
> 
> I think I need to write one anyway because I need to generate lots of tables other than the instruction table (there are no registers and therefore no register table), at least one for each subsection of section 3 of the spec and then some. Wether or not it is inside or outside of LLVM is irrelevant. What is, is that I’m not sure that the same can be said for intrinsics, which will enable the removal of the mangling hacks.
> 
>>> I am in the process of trying to make it “more traditional” where possible and it makes sense to do so, but I do not fully understand the backend pipeline and am just trying to express the intrinsics and binary format with tablegen at the moment. Regardless of the actual transformation pipeline used I think it should go in target for the advantages stated above, and the one that I missed was, it has its own target triples! Also IIRC the Mill CPUs will/(do?) only use one or two of the backend passes and I can’t imagine them not being considered targets.
>>>
>>
>> A "more traditional" backend is more than just using tablegen to generate
>> the instruction definitions.  It means implementing an instruction selector
>> and using SelectionDAG and MachineInstrs.  What I'm saying is that
>> SPIR-V is not a good fit for the existing infrastructure, so I think
>> it would be good to consider alternatives before going to far down that path.
> 
> Indeed, tablegen is the first step. I intend to incorporate as much of the standard pipeline as makes sense (e.g. no register allocation because there are no registers). As I have said I know very little about the backend pipeline so I can’t comment a whole lot. Is SelectionDAG matching pieces of the IR and choosing instruction from them? Because I definitely want to do that, if it is a thing (the tablegen files are currently dag free and do not inherit from `Instruction` because I do not understand that process, I am merely transcribing the spec), any information is welcome. 
> 
>> I think we may be using different definitions of driver in this case.
>> From the perspective of LDC, it doesn't seem like it would matter
>> much if LLVM IR -> SPIR-V were in the LLVM tree or outside of it.
>> In both cases you have a library that takes LLVM IR as input and
>> produces SPIR-V as output.
>>
>> -Tom
> 
> My point is that it is duplicated effort (i.e. one for LDC, one for clang and so on), and is redundant if it is a proper target. I am willing to put in the effort to allay concerns regarding the pipelining and legalisation, but I am steadfast in my opinion that it should be a target unless the benefits of not being a target can be shown to outweigh those of being a target. 
> 

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.
What you are proposing is a lot of work, and even if it does help to
avoid some duplicate work (which to be honest, I still don't quite
understand what duplication there would be if it weren't a target),
I don't think that is enough to justify the effort required.

-Tom