[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

[Neil Henning]

Hey Daniel!

So based on Philip and Chandler's points I really think the easiest way 
to integrate SPIR-V with LLVM is how I originally envisaged it - EG. we 
only put the production of SPIR-V within LLVM, and we integrate it fully 
as a backend.

It was under this assumption that my comment of "don't regress tests" is 
valid - EG. we would be a normal backend like the other backends and 
would have a similar testing approach to the other backends. In this 
regard the changes you mentioned that David Blaikie is doing wouldn't in 
theory require any extra work on his or anyone else's part.

I think if we follow this approach we provide the easiest method to 
integrate with LLVM, while putting no additional burden on the common 
infrastructure that is worrying the community so much :)

Cheers,
-Neil.

On 26/05/15 22:22, Daniel Berlin wrote:
> On Fri, May 22, 2015 at 9:29 AM, Philip Reames
> <listmail at philipreames.com> wrote:
>> Let me start by emphasizing that I only speak for myself.  This is my
>> opinion, and nothing more.
>>
>> On 05/22/2015 03:55 AM, Neil Henning wrote:
>>> 'Maintenance and support obligations' - the only maintenance obligations
>>> would be don't regress our tests when you change code, that is no different
>>> from doing changes to any other target.
>> I think SPIR as discussed is different in two potentially important ways:
>> - The lack of target information.  Can we even run IR passes over SPIR
>> derived IR and get back valid SPIR?  This hasn't been resolved.
>> - SPIR has explicit compatibility provisions across versions. Adding a
>> bi-directional converter makes the community responsible for preserving this
>> compatibility, even in face of otherwise breaking IR changes.  I haven't
>> seen this clearly discussed yet.
> Also, "don't regress tests" is a really strong obligation to impose if
> "doing normal things to LLVM IR allowed by LLVM langref" may break
> SPIR tests, because SPIR has stricter requirements and you test them
> (and, if you don't test them, then the target is certain to break).
> So as Philip says, this definitely sounds like something that needs
> some real resolution.
>
>
>>>
>>> Chandler raised some pretty important points in his reply, and we will
>>> need to address them. In Sam's original email he did say 'We are open to the
>>> SelectionDAG/MC approach if the community recommends it.' <- I would infer
>>> from Chandler's email that he is most definitely recommending this, and if
>>> the community as a whole believes this is the direction we should take then
>>> we are happy to proceed in that way.
>>>
>>> Really though our 'proposal' is that we have code that does bi-way
>>> conversion from LLVM IR <-> SPIR-V,
>
> And if you test this, as Philip says,  the llvm community becomes
> responsible for ensuring compatibility/figuring out ways to make this
> translation into SPIR (which uh, AFAICT, was developed in part because
> the llvm community didn't want to guarantee this :P).
>
> How do you propose that work, exactly (literally, i'm not suggesting
> it doesn't, i'm trying to understand the proposed moel)?
>
> Let me give a practical example:
>
> David Blaikie has been working on removing pointer types from some
> places and adding them in others, to remove requirements to bitcast
> pointers.
>
> This requires bitcode changes, and IR/langref changes.
>
> SPIR, even if it were to follow in the same path, does not in fact do
> this right now.
>
> In the LLVM bitcode/IR, one-way translation (from old bitcode to new)
> from old to new is easy.
> Two way translation from old to new is much harder (now he really has
> to have a pass to output bitcasts where they don't exist now to match
> the semantics of the old IR).  But that is what is essentially going
> to need to be done.
>
> Thus, if you test the SPIR translation of LLVM load/stores/geps, you
> would be affected by these changes.
> Do you expect David to write that part of a conversion pass/or update
> any existing conversion pass to make these changes to not break your
> tests?
>
> If so, you are asking the LLVM community to take on the burden of
> supporting the SPIR serialization, essentially, and that will
> significantly change the ability of the llvm community to innovate
> LLVM's IR.
> If not, what is the process you expect to be followed here?
>
> IE do you expect him to break you, wait for SPIR to decide whether
> they want to do the same thing, etc?